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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Digital Enhanced Cordless Telecommunications 
(DECT). 

The present document is based on EN 300 175 parts 1 [1] to 8 [8] and EN 300 444 [13]. General attachment 
requirements and speech attachment requirements are based on EN 301 406 [10] (replacing TBR 006 [25]) and 
EN 300 176-2 [9] (previously covered by TBR 010 [26]). 

The present document has been developed in accordance to the rules of documenting a profile specification as described 
in ISO/IEC 9646-6 [11]. 

The information in the present document is believed to be correct at the time of publication. However, DECT 
standardization is a rapidly changing area, and it is possible that some of the information contained in the present 
document may become outdated or incomplete within relatively short time-scales 

The present document is part 1 of a multi-part deliverable covering the New Generation DECT as identified below: 

Part 1: "Wideband speech"; 

Part 2: "Support of transparent IP packet data"; 
Part 3: "Support of phase 2 services". 
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1 Scope 

The present document specifies a set of functionalities of the New Generation DECT. 
The New Generation DECT provides the following basic new functionalities: 

• Wideband voice service. 

• Packet-mode data service supporting Internet Protocol with efficient spectrum usage and high data rates. 

The present document describes the first part: Wideband speech service. For the description of the support of 
transparent IP packet data, see TS 102 527-2 [14]. 

All New Generation DECT devices will offer at least one or both of these services. If the device offers the wideband 
voice service, it will support also the DECT standard 32 kbit/s voice service according to EN 300 444 (GAP) [13]. 

All DECT devices claiming to be compliant with this Application Profile will offer at least the basic services defined as 
mandatory. In addition to that, optional features can be implemented to offer additional DECT services. 

The aim of the present document is to guarantee a sufficient level of interoperability and to provide an easy route for 
development of DECT wideband speech applications, with the features of the present document being a common 
fall-back option available in all compliant to this profile equipment. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 300 444 [13] and the following apply: 

New Generation DECT: a further development of the DECT standard introducing wideband speech, improved data 
services, new slot types and other technical enhancements 

wideband speech: voice service with enhanced quality compared to ADPCM G.726 and allowing the transmission of a 
vocal frequency range of at least 150 Hz to 7 kHz, and fulfilling the audio performance requirements described in the 
ITU-T Recommendation P.31 1 [21] 

super-wideband speech: voice service with enhanced quality compared to ADPCM G.726 and allowing the 
transmission of a maximum vocal frequency of at least 14 kHz 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

M mandatory to support (provision mandatory, process mandatory) 

optional to support (provision optional, process mandatory) 

1 out-of-scope (provision optional, process optional) not subject for testing 
C conditional to support (process mandatory) 

N/A not applicable (in the given context the specification makes it impossible to use this capability) 

Provision mandatory, process mandatory means that the indicated feature service or procedure shall be implemented as 
described in the present document, and may be subject to testing. 

Provision optional, process mandatory means that the indicated feature, service or procedure may be implemented, and 
if implemented, the feature, service or procedure shall be implemented as described in the present document, and may 
be subject to testing. 

NOTE: The used notation is based on the notation proposed in ISO/IEC 9646-7 [12]. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAC Advanced Audio Coding (MPEG) 

AC Authentication Code 

ADPCM Adaptive Differential Pulse Code Modulation 

AI Air Interface 

BCD Binary Coded Decimal 

CC Call Control 

CI Common Interface 

DECT Digital Enhanced Cordless Telecommunications 

DLC Data Link Control 

DTMF Dual Tone Multi-Frequency 

ER Error Resilient (MPEG) 

FP Fixed Part 

FT Fixed radio Termination 

GAP Generic Access Profile 

GAP Generic Access Profile 

IA Implementation Alternative 

IE Information Element 

IP Internet Protocol 

IPUI International Portable User Identity 

ISDN Integrated Services Digital Network 



ETSI 



11 



ETSI TS 102 527-1 V1.1.1 (2007-04) 



IWU InterWorking Unit 

KS PP authentication Session Key 

LA Location Area 

LD Low Delay (MPEG) 

LLME Lower Layer Management Entity 

LSB Least Significant Bit 

MAC Medium Access Control 

MM Mobility Management 

MSB Most Significant Bit 

NB Narrow Band 

NG New Generation 

NG-DECT New Generation DECT 

NWK NetWorK 

P Public (environment) 

PA Portable Application 

PABX Private Automatic Branch eXchange 

PARK Portable Access Rights Key 

PHL PHysical Layer 

PP Portable Part 

PRA Primary Rate Access (ISDN) 

PT Portable radio Termination 

R/B Residential/Business (environment) 

RFP Radio Fixed Part 

S/T ISDN S/T Interface 

SARI Secondary Access Rights Identity 

TCL Telephone Coupling Loss 

TPUI Temporary Portable User Identity 

TRUP TRansparent Unprotected service 

U ISDN U-Interface 

WB Wideband 



4 Description of Services 

4.1 Enhanced wideband speech 

In traditional telephony applications the supported bandwidth is 3,1 kHz (300 Hz to 3,4 kHz). For better speech quality 
and a more natural sound, a bandwidth of at least 150 Hz to 7 kHz should be supported and may be extended even 
further. 

New Generation DECT improves audio quality by implementing wideband enhanced quality audio codecs. All New 
Generation DECT wideband speech devices shall implement wideband (150 Hz to 7 kHz) audio (16 kHz frequency 
sampling). DECT devices supporting wideband audio shall support the speech coding format according to 
ITU-T Recommendation G.722 [17]. In addition to that, other wideband and superwideband audio codecs, providing 
even better audio quality, may be implemented. 

In order to transport the higher bitrate of the new enhanced codecs, the bitrate per channel at the air interface is doubled 
from 32 kbit/s in traditional DECT to 64 kbit/s. 

All New Generation DECT wideband speech devices shall be backward compatible with traditional DECT 32 kbit/s 
voice (GAP) devices. New PPs shall operate with legacy base stations, and new bases shall support existing PPs. In 
such cases, the voice quality is the traditional DECT quality (32 kbit/s ADPCM). 

4.1 .1 Audio performance requirements 

New Generation DECT handsets shall fulfil the audio performance requirements described in 
ITU-T Recommendation P.31 1 [21]. 
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4.2 Wideband speech scenarios 

The following scenarios are envisaged: 

4.2.1 Internal calls inside a New Generation DECT system 

In such a case, wideband (150 Hz to 7 kHz) communication is possible between both terminals without any special 
issue. 





Figure 1 : Internal wideband call 



4.2.2 Calls between two New Generation DECT systems interconnected 
by ISDN 

Two subscribers owning New Generation DECT base stations and handsets could establish a wideband voice 
communication between them if the DECT FPs are interconnected by an ISDN network with digital U or S/T interface, 
(or PRA) to the local exchange. The ISDN call should be digital unrestricted 64 kbit/s. 

The scenario is also possible for business customers using PABX with DECT support and digital links to the public 
exchange. 



I 




Figure 2: Wideband call via ISDN 
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4.2.3 Calls between two New Generation DECT systems interconnected 
by IP packet based network 

Two subscribers owning New Generation DECT base stations and handsets, and interconnected via VoIP over an IP 
packet based network, could establish a wideband voice communication between them. 



The IP packed based network can be either the Internet or a dedicated IP based network. 




i 



Figure 3: Wideband call via Internet 

4.2.4 Calls between a New Generation DECT system and a digital phone 
supporting compatible codecs 

This scenario is possible, at least in the following cases: 

4.2.4.1 Via ISDN 

ISDN digital phones with S/T interface and supporting the ITU-T Recommendation G.722 [17] codec could establish 
wideband calls with New Generation DECT equipment. Identical scenario is possible for PABX digital terminals 
calling or called by New Generation DECT systems. 



4.2.4.2 



Via IP network 



Digital phones with a VoIP interface could also establish wideband communications with New Generation DECT 
equipment. This scenario includes both, dedicated VoIP phone devices and computers implementing the necessary 
software. Due to the evolution of computer industry, nearly all modern Personal Computers have the capability to 
become a wideband phone with DECT compatible codecs. 



4.2.4.3 



Internal PABX calls 



PABX supporting New Generation DECT and digital extensions with compatible wideband codecs could also benefit 
from the wideband voice quality for their internal calls. 



4.2.5 Legacy scenarios 



Existing DECT GAP compliant equipment (both FT and PT) should be able to interoperate with New Generation DECT 
systems. In such cases, communication will be traditional 32 kbit/s ADPCM voice links. 

Interoperability shall be possible in both directions: 

• A new Generation DECT wideband speech PT should be interoperable with legacy DECT FTs. 

• A legacy PT should be interoperable with new Generation DECT FTs. 
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5 Service and feature definitions 

5.1 New Generation DECT Speech Services 

For the purposes of the present document, the following definitions shall apply: 

Narrow band ADPCM G.726 voice service (NG1.1): ITU-T Recommendation G.726 [15] narrow band codec 
(NG1.SC.1) over 32 kbit/s unprotected transmission channel 

Narrow band PCM G.711 voice service (NG1.2): ITU-T Recommendation G.71 1 [16] narrow band codec 
(NG1.SC.2) over 64 kbit/s protected or unprotected transmission channels 

Wideband 7 kHz G.722 voice service (NG1.3): ITU-T Recommendation G.722 [17] wideband codec (NG1.SC.3) 
over 64 kbit/s protected or unprotected transmission channels 

Wideband 7 kHz low rate G.729.1 voice service (NG1.4): ITU-T Recommendation G.729.1 [18] wideband codec 
(NG1.SC.4) over 32 kbit/s unprotected transmission channels 

Super wideband 14 kHz MPEG-4 ER AAC-LD voice service (NG1.5): MPEG-4 ER AAC-LD super wideband 
codec (NG1.SC.5) over 64 kbit/s protected or unprotected transmission channels 

Wideband 11 kHz low rate MPEG-4 ER AAC-LD voice service (NG1.6): MPEG-4 ER AAC-LD super wideband 
codec (NG1.SC.6) over 32 kbit/s unprotected transmission channels 

5.2 Network (NWK) features 

For the purposes of the present document, all definitions of EN 300 444 [13] clause 4. 1 , plus the following shall apply: 

Codec Negotiation (NG1.N.1): capability to negotiate the speech codec to be used in a communication, based on the 
supported capabilities in both peers and the previsions included in the present document. This feature may require slot 
type change 

Codec Switching (NG1.N.2): capability to switch between different speech codecs during a call. This feature may 
require slot type change 

5.3 Data Link Control (DLC) service definitions 

For the purposes of the present document, all definitions of EN 300 444 [13] clause 5.1 plus the following shall apply: 

LU1 Transparent Unprotected service (TRUP) Class 0/minimum_delay (NG1.D.1): transparent unprotected 
service introducing minimum delay , transmission Class 0/min_delay as defined by EN 300 175-4 [4] clause 1 1.2 

LU1 Transparent Unprotected service (TRUP) Class (NG1.D.2): transparent unprotected service introducing 
minimum delay , transmission Class as defined by EN 300 175-4 [4] clause 1 1.2 

LU7 64 kbit/s protected bearer service (NG1.D.3): protected service providing reliable 64 kbit/s transmission over 
packet type P80 incorporating FEC and ARQ protection mechanisms. Defined by EN 300 175-4 [4] clause 1 1.9 

FU1 DLC frame (NG1.D.4): bidirectional frame used in LU1 service. Defined in EN 300 175-4 [4] clause 12.2. Frame 
length depends on slot type and is defined in table 12.2.1.1 of EN 300 175-4 [4] clause 12.2.1 

FU7 DLC frame (NG1.D.5): bidirectional frame used in LU7 service. Defined in EN 300 175-4 [4] clause 1 1.9 
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5.4 Medium Access Control (MAC) service definitions 

For the purposes of the present document, all definitions of EN 300 444 [13] clause 5.2 plus the following shall apply: 

I N _minimum delay symmetric MAC service type (NG1.M.1): I N _minimum delay symmetric connection as defined 
in EN 300 175-3 [3] clause 5.6.2.1 

I N _normal delay symmetric MAC service type (NG1.M.2): I N _normal delay symmetric connection as defined in 

EN 300 175-3 [3] clause 5.6.2.1 

IpQ_error_detection symmetric MAC service type (NG1.M.3): Ipq_ error_detection symmetric connection as defined 
in EN 300 175-3 [3] clause 5.6.2.1. (type 3: Ip_ error_detection with single-subfield protected B-field as defined in [3] 
clause 6.2.1.3.4) 

5.5 Physical Layer (PHL) service definitions 

For the purposes of the present document the following definitions shall apply: 

2 level GFSK modulation (NG1.P.1): 2 level Gaussian frequency Shift Key (GFSK) modulation as defined by 

EN 300 175-2 [2] clause 5 

Physical Packet P32 (NG1.P.2): physical packet P32 (full slot) as defined by EN 300 175-2 [2] clause 4.4.2 

Physical Packet P64 (NG1.P.3): variable capacity Physical packet POOj as defined by EN 300 175-2 [2] clause 4.4.3, 
withj =640 

Physical Packet P67 (NG1.P.4): variable capacity Physical packet POOj as defined by EN 300 175-2 [2] clause 4.4.3, 
with j = 672 

Physical Packet P80 (NG1.P.5): physical packet P80 (double slot) as defined by EN 300 175-2 [2] clause 4.4.4 

5.6 Speech coding service definitions 

For the purposes of the present document the following definitions shall apply: 

G.726 32 kbit/s ADPCM (NG1.SC.1): ITU-T Recommendation G.726 [15] narrow band codec 15 as defined by 
EN 300 175-8 [8] clause 5.1. ITU-T Recommendation G.726 [15] codec is mandatory for New Generation DECT in 
order to ensure interoperability with existing DECT systems 

G.711 64 kbit/s log-PCM (NG1.SC.2): ITU-T Recommendation G.71 1 narrow band codec [16] as defined by 

EN 300 175-8 [8] clause 5.2. ITU-T Recommendation G.71 1 [16] codec is optional for New Generation DECT in order 

to improve the quality of narrow band communications, and fax/modem transmissions. ITU-T Recommendation G.71 1 

[16] provides a slightly higher intrinsic voice quality and no transcoding for PSTN calls. Both, A-Law and |i-Law are 

supported 

G.722 64 kbit/s wideband (NG1.SC.3): ITU-T Recommendation G.722 wideband SB-ADPCM 7 kHz codec [17] as 
defined by EN 300 175-8 [8] clause 5.3. ITU-T Recommendation G.722 [17] is chosen as mandatory wideband codec 
for New Generation DECT in order to greatly increase the voice quality by extending the bandwidth from narrow band 
to wideband. ITU-T Recommendation G.722 [17] provides a high wideband quality at a bit rate of 64 kbit/s with low 
complexity and very low delay 

G.729.1 32 kbit/s wideband (NG1.SC.4): ITU-T Recommendation G.729.1 wideband codec [18] as defined by 
EN 300 175-8 [8] clause 5.4. ITU-T Recommendation G.729.1 [18] codec is optional for New Generation DECT in 
order to provide even higher wideband quality and better robustness to packets/frames losses than 
ITU-T Recommendation G.722 [17] at half the bit rate of ITU-T Recommendation G.722 [17]. This allows a better 
transport efficiency on the network side and over the DECT air interface (one full slot). In addition, it is seamless 
interoperable with largely deployed ITU-T Recommendation G.729 (see bibliography) based VoIP networks and 
terminals. ITU-T Recommendation G.729.1 [18] encodes signals in frames of 20 ms. It is a scalable codec operating at 
bitrates of 8 kbit/s and from 12 kbit/s to 32 kbit/s per steps of 2 kbit/s, in narrow band or in wideband from 14 kbit/s. 
ITU-T Recommendation G.729.1 [18] already incorporates a high efficiency packet loss concealment mechanism 
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MPEG-4 ER AAC-LD 64 kbit/s super wideband (NG1.SC.5): MPEG-4 ER AAC-LD codec [17] as defined by 
EN 300 175-8 [8] clause 5.5.1. MPEG-4 ER AAC-LD is optional for New Generation DECT in order to provide higher 
quality than G.722 by further extending the bandwidth to superwideband (50 Hz to 14 kHz) (and even further, up to full 
audio bandwidth (20 Hz to 20 kHz)). MPEG-4 ER AAC-LD is designed for high quality communication applications 
including all kind of audio signals e.g. speech and music and provides a high quality for music streaming or other 
multimedia applications mixing speech and music. It provides an audio bandwidth of 14 kHz or more at a bitrate of 64 
kbit/s. MPEG 4 ER AAC-LD is standardized in ISO/IEC 14496-3 [20]. The frame size is 10 ms and the algorithmic 
delay 20 ms 

MPEG-4 ER AAC-LD 32 kbit/s wideband (NG1.SC.6): as (NG1.SC5), but using the 32 kbit/s mode, as defined by 

EN 300 175-8 [8] clause 5.5.2. It provides a bandwidth of 1 1,5 kHz or more. The frame size is 20 ms and the 
algorithmic delay 40 ms 

PLC (Packet Loss Concealment) G.722 Appendix III & IV (NG1.SC.7): to better cope with transmission errors, a 
Packet Loss Concealment algorithm (PLC) as defined by EN 300 175-8 [8] clause 5.3.2 may be optionally implemented 
for ITU-T Recommendation G.722 [17]. Appendices III and IV describe packet loss concealment solutions extending 
the ITU-T Recommendation G.722 [17] decoder. These PLC algorithms may be optionally implemented to improve 
voice quality in degraded transmission conditions where packets/frames may be lost (in IP network or on DECT air 
interface) 

NOTE 1 : Both appendices meet the same quality requirements but address two different quality/complexity trade 
offs: 

1) Appendix III aims at maximizing the robustness at a price of additional complexity. 

2) Appendix IV proposes an optimized complexity/quality trade off with almost no additional complexity 
compared with ITU-T Recommendation G.722 [17] normal decoding (0,07 WMOPS). 

Since ITU-T Recommendation G.722 [17] does not incorporate any mechanism to cope with lost frames/packets, the 
use of a PLC algorithm is strongly recommended to avoid annoying effects in case of packet/frame losses. 

NOTE 2: ITU-T Recommendation G.729.1 [18] already incorporates a packet loss concealment mechanism. 

Detection of Modem/fax tone (NG1.SC.8): detection of the 1 100 Hz, 1 300 Hz and 2 100 Hz standard tones 
indicating a fax/modem transmission and answering, as defined by EN 300 175-8 [8] clause 5.2.2. The main utility of 
this function is the switching of codecs to transparent PCM (ITU-T Recommendation G.71 1 [16]) in order to facilitate 
modem/fax transmission. The tone detection can also be used to de-activate echo suppression if present 

Codec selection and switching (NG1.SC.9): to handle several codecs (at least ITU-T Recommendation G.726 [15] and 
ITU-T Recommendation G.722 [17]), New Generation DECT will support a codec selection and switching mechanism. 
This may consequently allow the use of other codecs that could be specified in next releases as additional optional 
codecs according to future application or interoperability needs 

5.7 Application features 

For the purposes of the present document, all definitions of EN 300 444 [13] clause 4.2 shall apply: 



Inter-operability requirements 



6.1 General 

The tables listed in this clause define the status of all protocol elements (i.e. features, services, and procedures) which 
can be: mandatory, optional, conditional under the provision of another protocol element, outside the scope of the 
present document, or not applicable. The status is identified by the status column designations defined in clause 3.2, and 
is described separately for FT and PT. In the case of FT, the status can be different for products intended for the 
Residential/Business (R/B) market or for the Public market segment. 

All optional elements shall be process mandatory according to the procedures described in the present document. 
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Protocol elements defined as mandatory, optional or conditional in this clause are further defined in the referenced 
DECT specification, or, if needed, in clause 7 of the present document. 

New Generation DECT wideband speech is defined as a backcompatible enhancement of DECT Generic Access Profile 
(GAP) [13]. All procedures not specific of the New Generation DECT, are referenced to their original description in 
EN 300 444 (GAP) [13]. 

NOTE: Annexes A and D are informative and may be used as additional information, but do not mandate 
requirements. Annexes B, C, E, and F are normative. 

The requirements of EN 301 406 [10] and EN 300 176-2 [9] shall be met by all equipment conforming to the present 
document. 

6.2 New Generation DECT Speech Services support status 

The following end-user services shall be supported by New Generation DECT wideband voice specification: 

Table 1 : Speech service status 



Feature supported 




Status 


Item no. 


Name of Service 


Reference 


PT 


FT 










R/B 


P 


NG1.1 


Narrow band ADPCM G.726 32 kbit/s voice service 


5.1 


M 


M 


M 


NG1.2 


Narrow band PCM G.71 1 64 kbit/s voice service 


5.1 


O 


O 


O 


NG1.3 


Wideband G.722 64 kbit/s voice service 


5.1 


M 


M 


M 


NG1.4 


Wideband G.729.1 32 kbit/s voice service 


5.1 


O 


O 


O 


NG1.5 


MPEG-4 ER AAC-LD super wideband 64 kbit/s voice service 


5.1 


O 


O 


O 


NG1.6 


MPEG-4 ER AAC-LD wideband 32 kbit/s voice service 


5.1 





O 


O 



6.3 Services to DECT feature implementation mappings 

New Generation DECT services shall be implemented using the following DECT services and features, according to the 
following implementation alternatives: 

Table 2: Speech service to DECT features implementation mappings 



Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 












R/B 


P 


NG1.1 Narrow band ADPCM 
G.726 32 kbit/s voice service 


I 




5.1 


M 


M 


M 


NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.2 Physical Packet P32 


5.5 


M 


M 


M 


NG1.M.1 iNjninimum delay symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP Class 
0/min delay 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 


NG1.SC.1 ITU- 

T Recommendation G.726 [15] 32 kbit/s 

ADPCM codec 


5.6 


M 


M 


M 


NG1.2 Narrow band PCM G.711 
64 kbit/s voice service 


I 




5.1 


O 


O 


O 


NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.3 Physical Packet P64 


5.5 


M 


M 


M 


NG1.M.1 INjninimum delay symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP Class 
0/min delay 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 












R/B 


P 






NG1.SC.2ITU- 

T Recommendation G.71 1 [16] 64 kbit/s 

PCM codec 


5.6 


M 


M 


M 


NG1.SC.8 Detection of Fax/modem 
tone 


5.6 











NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


NG1.2 Narrow band PCM G.711 
64 kbit/s voice service 


II 




5.1 











NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.4 Physical Packet P67 


5.5 


M 


M 


M 


NG1.M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP 
Class 0/min delay 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 


NG1.SC.2ITU- 

T Recommendation G.71 1 [16] 64 kbit/s 

PCM codec 


5.6 


M 


M 


M 


NG1.SC.8 Detection of Fax/modem 
tone 


5.6 











NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


NG1.2 Narrow band PCM G.711 
64 kbit/s voice service 


III 




5.1 











NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.5 Physical Packet P80 


5.5 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1 .D.3 DLC Service LU7 64 kbit/s 
protected bearer 


5.3 


M 


M 


M 


NG1.D.5 DLC frame FU7 


5.3 


M 


M 


M 


NG1.SC.2ITU- 

T Recommendation G.71 1 [16] 64 kbit/s 

PCM codec 


5.6 


M 


M 


M 


NG1.SC.8 Detection of Fax/modem 
tone 


5.6 











NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


NG1.3 Wideband 7 kHz G.722 
64 kbit/s voice service 


I 




5.1 


M 


M 


M 


NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.3 Physical Packet P64 


5.5 


M 


M 


M 


NG1.M.1 iNjninimum delay symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP 
Class 0/min delay 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 


NG1.SC.3mj- 

T Recommendation G.722 [17] 64 kbit/s 

7 kHz wideband codec 


5.6 


M 


M 


M 


NG1.SC.7 Packet loss Concealment 
(PLC) for G.722 


5.6 











NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


NG1.3 Wideband 7 kHz G.722 
64 kbit/s voice service 


II 




5.1 











NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.3 Physical Packet P67 


5.5 


M 


M 


M 


NG1.M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP 
Class 0/min delay 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 
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Service/DECT Feature mapping 




Status 


Service 


IA 


DECT feature/service 


Reference 


PT 


FT 












R/B 


P 






NG1.SC.3ITU- 

T Recommendation G.722 [17] 64 kbit/s 

7 kHz wideband codec 


5.6 


M 


M 


M 


NG1.SC.7 Packet loss Concealment 
(PLC) for ITU-T Recommendation 
G.722 [17] 


5.6 











NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


NG1.4 Wideband 7 kHz G.729.1 
32 kbit/s voice service 


I 




5.1 











NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.3 Physical Packet P32 


5.5 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1 .D.2 DLC Service LU1 TRUP 
Class 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 


NG1.SC.4 ITU-T Recommendation 
G.729.1 [18] 32 kbit/s 7 kHz wideband 
codec 


5.6 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


NG1.5 Superwideband 14 kHz 
MPEG-4 ER AAC-LD 64 kbit/s 
voice service 


I 




5.1 











NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.3 Physical Packet P64 


5.5 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1 .D.2 DLC Service LU1 TRUP 
Class 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 


NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 14 
kHz superwideband codec 


5.6 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


NG1.5 Superwideband 14 kHz 
MPEG-4 ER AAC-LD 64 kbit/s 
voice service 


II 




5.1 











NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.3 Physical Packet P67 


5.5 


M 


M 


M 


NG1.M.3 lpQ_error_detection symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP 
Class 0/min delay 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 


NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 
14 kHz superwideband codec 


5.6 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


NG1.6 Wideband 11 kHz MPEG- 
4 ER AAC-LD 32 kbit/s voice 
service 


I 




5.1 











NG1.P.1 2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.3 Physical Packet P32 


5.5 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
MAC service type 


5.4 


M 


M 


M 


NG1.D.2 DLC Service LU1 TRUP 
Class 


5.3 


M 


M 


M 


NG1.D.4 DLC frame FU1 


5.3 


M 


M 


M 


NG1 .SC.6 MPEG4 AAC-LD 32 kbit/s 
1 1 kHz wideband codec 


5.6 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 


M 


M 


M 


IA = Implementation Alternative 
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6.4 



NWK features 



New Generation DECT wideband speech devices shall support the following Network layer features: 

Table 3: NWK features status 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 










R/B 


p 


NG1.N.1 


Codec Negotiation 


5.2 


M 


M 


M 


NG1.N.2 


Codec Switching 


5.2 


M 


M 


M 


GAP.N.1 


Outgoing call 


4.1 [13] 


M 


M 


M 


GAP.N.2 


Off hook 


4.1 [13] 


M 


M 


M 


GAP.N.3 


On hook (full release) 


4.1 [13] 


M 


M 


M 


GAP.N.4 


Dialled digits (basic) 


4.1 [13] 


M 


M 


M 


GAP.N.5 


Register recall (note 4 and note 5) 


4.1 [13] 


M 


O 


O 


GAP.N.6 


Go to DTMF signalling (defined tone length) (note 1) 


4.1 [13] 


M 


O 


M 


GAP.N.7 


Pause (dialling pause) (note 3) 


4.1 [13] 


M 


O 


O 


GAP.N.8 


Incoming call 


4.1 [13] 


M 


M 


M 


GAP.N.9 


Authentication of PP 


4.1 [13] 


M 


O 


M 


GAP.N10 


Authentication of user (note 2) 


4.1 [13] 


M 


O 


O 


GAP.N.1 1 


Location registration 


4.1 [13] 


M 


O 


M 


GAP. N. 12 


On air key allocation (note 2) 


4.1 [13] 


M 





O 


GAP. N. 13 


Identification of PP 


4.1 [13] 


M 





O 


GAP. N. 14 


Service class indication/assignment 


4.1 [13] 


M 





M 


GAP. N. 15 


Alerting 


4.1 [13] 


M 


M 


M 


GAP. N. 16 


ZAP (note 2) 


4.1 [13] 


M 


O 


O 


GAP. N. 17 


Encryption activation FT initiated 


4.1 [13] 


M 


O 


M 


GAP. N. 18 


Subscription registration procedure on-air 


4.1 [13] 


M 


M 


M 


GAP. N. 19 


Link control 


4.1 [13] 


M 


M 


M 


GAP.N.20 


Terminate access rights FT initiated (note 2) 


4.1 [13] 


M 


O 


O 


GAP.N.21 


Partial release 


4.1 [13] 


O 


O 


O 


GAP.N.22 


Go to DTMF (infinite tone length) 


4.1 [13] 


O 


O 


O 


GAP.N.23 


Go to Pulse 


4.1 [13] 


O 


O 


O 


GAP.N.24 


Signalling of display characters 


4.1 [13] 


O 


O 


O 


GAP.N.25 


Display control characters 


4.1 [13] 


O 





O 


GAP.N.26 


Authentication of FT 


4.1 [13] 


O 





O 


GAP.N.27 


Encryption activation PT initiated 


4.1 [13] 


O 





O 


GAP.N.28 


Encryption deactivation FT initiated 


4.1 [13] 


O 





O 


GAP.N.29 


Encryption deactivation PT initiated 


4.1 [13] 


O 





O 


GAP.N.30 


Calling Line Identification Presentation (CLIP) 


4.1 [13] 


M 


M 


M 


GAP.N.31 


Internal call 


4.1 [13] 


O 





O 


GAP.N.32 


Service call 


4.1 [13] 


O 





O 


GAP.N.33 


Enhanced U- plane connection 


4.1 [13] 











GAP.N.34 


Calling Name Identification Presentation (CNIP) 


4.1 [13], 
F.1.2.1 











NOTE 1 : The PT is only required to be able to send the «MULTI-KEYPAD» information element containing the 

DECT standard 8-bit character (EN 300 175-5 [5], annex D) codings "Go to DTMF", defined tone length 

and the FT is required to be able to understand it in the public environment. 
NOTE 2: This feature is required to be supported in the PT to guarantee the same level of security among all the 

handsets that operates in a system. The invocation of the feature is however optional to the operator. 
NOTE 3: The PT is required to be able to send the «MULTI-KEYPAD» information element containing the DECT 

standard 8-bit character (EN 300 175-5 [5], annex D) codings "Dialling Pause". This guarantees 

automatic access to secondary or alternative networks. 
NOTE 4: This feature uses keypad code 1 5 hex. 
NOTE 5: The FT is not mandated to receive and understand the register recall DECT character. However, if a FT 

supports it there may be no corresponding action that the FT can take with the local network as a result of 

this function. 



ETSI 



21 



ETSI TS 102 527-1 V1.1.1 (2007-04) 



6.5 Data Link Control (DLC) services 

New Generation DECT wideband speech devices shall support the following DLC services: 

Table 4: DLC services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 










R/B 


P 


NG1.D.1 


LU1 Transparent Unprotected service (TRUP) Class 
/minimum delay 


5.3 


M 


M 


M 


NG1.D.2 


LU1 Transparent Unprotected service (TRUP) Class 


5.3 


C401 


C401 


C401 


NG1.D.3 


LU7 64 kbit/s protected bearer service 


5.3 


C401 


C401 


C401 


NG1.D.4 


FU1 DLC frame 


5.3 


M 


M 


M 


NG1.D.5 


FU7 DLC frame 


5.3 


C401 


C401 


C401 


GAP.D.1 


LAPC class A service and Lc 


5.1 [13] 


M 


M 


M 


GAP.D.2 


Cs channel fragmentation and recombination 


5.1 [13] 


M 


M 


M 


GAP.D.3 


Broadcast Lb service 


5.1 [13] 


M 


M 


M 


GAP.D.4 


Intra-cell voluntary connection handover 


5.1 [13] 


M 


C402 


C402 


GAP.D.5 


Intercell voluntary connection handover (note) 


5.1 [13] 


M 








GAP.D.6 


Encryption activation 


5.1 [13] 


M 


C404 


M 


GAP.D.7 


LU1 TRUP Class 0/min delay 


5.1 [13] 


M 


M 


M 


GAP.D.8 


FU1 


5.1 [13] 


M 


M 


M 


GAP.D.9 


Encryption deactivation 


5.1 [13] 


C403 


C403 


C403 


NOTE: The PT is required to be able to support handover between RFPs. The invocation of the feature is 
however optional to the operator. 


C401 
C402 
C403 
C404 


Status defined by clause 6.3, table 2. 

IF service GAP.M.9 THEN ELSE M. 

IF feature GAP.N.29 OR N.28 THEN M ELSE I. 

IF feature GAP.N.1 7 OR N.27 THEN M ELSE I. 



ETSI 



22 



ETSI TS 102 527-1 V1.1.1 (2007-04) 



6.6 Medium Access Control (MAC) services 

New Generation DECT wideband speech devices shall support the following MAC layer services: 

Table 5: MAC services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 










R/B 


P 


NG1.M.1 


In minimum delay symmetric MAC service type 


5.4 


M 


M 


M 


NG1.M.2 


In normal delay symmetric MAC service type 


5.4 


C501 


C501 


C501 


NG1.M.3 


Ipq error detection symmetric MAC service type 


5.4 


C501 


C501 


C501 


GAP.M.1 


General 


5.2 [13] 


M 


M 


M 


GAP.M.2 


Continuous broadcast 


5.2 [[13] 


M 


M 


M 


GAP.M.3 


Paging broadcast 


5.2 [13] 


M 


M 


M 


GAP.M.4 


Basic connections 


5.2 [13] 


M 


M 


M 


GAP.M.5 


Cs higher layer signalling 


5.2 [13] 


M 


M 


M 


GAP.M.6 


Quality control 


5.2 [13] 


M 


M 


M 


GAP.M.7 


Encryption activation 


5.2 [13] 


M 


C505 


M 


GAP.M.8 


Extended frequency allocation (note) 


5.2 [13] 


M 








GAP.M.9 


Bearer Handover, intra-cell 


5.2 [13] 


M 


C502 


C502 


GAP.M.10 


Bearer Handover, inter-cell 


5.2 [13] 


M 








GAP.M.1 1 


Connection Handover, intra-cell 


5.2 [13] 


M 


C503 


C503 


GAP.M.12 


Connection Handover, inter-cell 


5.2 [13] 


M 








GAP.M.13 


SARI support 


5.2 [13] 


M 








GAP.M.14 


Encryption deactivation 


5.2 [13] 


C504 


C504 


C504 


NOTE: Handsets not supporting these extra frequencies need only adapt scanning to allow continued use of the 
standard DECT frequencies. 


C501 
C502 
C503 
C504 
C505 


Status defined by clause 6.3, table 2. 

IF service GAP.M.1 1 THEN ELSE M. 

IF service GAP.M.9 THEN ELSE M. 

IF feature GAP.N.29 OR N.28 THEN M ELSE I. 

IF feature GAP.N.1 7 OR N.27 THEN M ELSE I. 



6.7 Physical layer (PHL) services 

New Generation DECT wideband speech devices shall support the following Physical layer (PHL) services: 

Table 6: PHL services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 










R/B 


P 


NG1.P.1 


2 level GFSK modulation 


5.5 


M 


M 


M 


NG1.P.2 


Physical Packet P32 


5.5 


M 


M 


M 


NG1.P.3 


Physical Packet P64 


5.5 


M 


M 


M 


NG1.P.4 


Physical Packet P67 


5.5 











NG1.P.5 


Physical Packet P80 


5.5 














The requirements of EN 300 444 [13] clause 11 also apply. 
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6.8 Speech codecs 

New Generation DECT wideband speech devices shall support the following Speech codecs and related services: 

Table 7: Speech Codecs 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 










R/B 


P 


NG1.SC.1 


G.726 32 kbit/s ADPCM codec 


5.6 


M 


M 


M 


NG1.SC.2 


G.71 1 64 kbit/s PCM codec 


5.6 


C701 


C701 


C701 


NG1.SC.3 


G.722 64 kbit/s 7 kHz wideband codec 


5.6 


M 


M 


M 


NG1.SC.4 


G. 729.1 32 kbit/s 7 kHz wideband codec 


5.6 


C701 


C701 


C701 


NG1.SC.5 


MPEG4 AAC-LD 64 kbit/s 14 kHz superwideband codec 


5.6 


C701 


C701 


C701 


NG1.SC.6 


MPEG4 AAC-LD 32 kbit/s 1 1 kHz wideband codec 


5.6 


C701 


C701 


C701 


NG1.SC.7 


Packet loss Concealment (PLC) for G.722] 


5.6 


C701 


C701 


C701 


NG1.SC.8 


Detection of Fax/modem tone 


5.6 


C701 


C701 


C701 


NG1.SC.9 


Codec selection and switching 


5.6 


M 


M 


M 


C701 : Status defined by clause 6.3, table 2. 



6.9 Application features 

New Generation DECT wideband speech devices shall support the following Application features: 

Table 8: Application features status 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 










R/B 


P 


GAP.A.1 


AC bitstring mapping 


4.2 [13] 


M 


C801 


M 


GAP.A.2 


Multiple subscription registration 


4.2 [13] 


M 


N/A 


N/A 


GAP.A.3 


Manual entry of the PARK 


4.2 [13] 





N/A 


N/A 


GAP.A.4 


Terminal identity number assignment in mono cell system 


4.2 [13], 
F.1.4.1 








N/A 


C801 : IF feature GAP.N.9 OR GAP.N.10 OR N.12 OR N.26 THEN M ELSE N/A. 
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6.1 Network (NWK) feature to procedure mapping 

The NWK features to procedure mapping of EN 300 444 (GAP) [13], clause 6.7 apply with the following changes and 
additional features: 

Table 9: NWK feature to procedure mapping 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 










R/B 


P 


NG1.N.1 Codec Negotiation 




5.2 


M 


M 


M 


Exchange of codec list during registration 
and location registration 


7.2.1 


M 


M 


M 


Basic service wideband speech and 
default attributes 


7.2.2 


M 


M 


M 


Codec Negotiation during call 
establishment 


7.2.3 


M 


M 


M 












NG1.N.2 Codec Switching 




5.2 


M 


M 


M 


Codec Change 


7.2.4 


M 


M 


M 


Slot type modification 


7.2.5 


M 


M 


M 


MAC layer advanced connection: service 
type or slot type modification 


10.3.2 [3] 








MAC layer connection type modification 


10.3.3 [3] 


M 


M 


M 


GAP.N.31 Internal Call 




4.1 [13] 


O 


O 


O 


Internal call setup 


7.3.4 


M 


M 


M 


Internal call keypad 


8.19 [13] 


M 


O 


O 


Internal call CLIP 


F.1.3.2 


O 


O 


O 


Internal call CNIP 


F.1.3.3 


O 


O 
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6.1 1 Data Link Control (DLC) Service to procedure mapping 

The DLC service to procedure mapping of EN 300 444 (GAP) [13], clause 6.8.1 apply with the following changes and 
additional services: 

Table 10: DLC service to procedure mapping 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 










R/B 


P 


NG1.D.1 LU1 Transparent 
Unprotected service (TRUP) 
Class 0/minimum_delay 




5.3 


M 


M 


M 


LU1 Transparent Unprotected service 
(TRUP) operation 


1 1 .2 [4] 


M 


M 


M 


Class 0: No Lu x retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


Minimum delay (speech) operation 


14.2.3 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [13] 


M 


M 


M 


NG1.D.2 LU1 Transparent 
Unprotected service (TRUP) 
Class 




5.3 


O 


O 


O 


LU1 Transparent Unprotected service 
(TRUP) operation 


1 1 .2 [4] 


M 


M 


M 


Class 0: No Lu x retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [13] 


M 


M 


M 


NG1 .D.3 LU7 64 kbit/s protected 
bearer service 






O 


O 


O 


LU7 DLC layer service 


1 1 .9.4 [4] 


M 


M 


M 


NG1.D.4FU1 DLC frame 






O 


O 


O 


FU1 frame operation 


7.9.1 


M 


M 


M 


FU1 frame structure 


1 2.2 [4] 


M 


M 


M 


NG1.D.5FU7 DLC frame 






O 


O 


O 


FU7 frame structure 


11.9.4.2 [4] 


M 


M 


M 
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6.12 Medium Access Control (MAC) service to procedure 
mapping 

The MAC service to procedure mapping of EN 300 444 (GAP) [13], clause 6.8.2 apply with the following changes and 
additional services: 

Table 11 : MAC service to procedure mapping 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 










R/B 


P 


NG1M.1 iNjninimum delay 
symmetric MAC service type 




5.4 


M 


M 


M 


MAC layer procedures: general 


7.9.1 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_minimum delay symmetric MAC 
service, type 1 


5.6.2.1 [3] 


M 


M 


M 


NG1 .M.2 l N _normal delay 
symmetric MAC service type 






O 


O 


O 


MAC layer procedures: general 


7.9.1 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_normal delay symmetric MAC service 
type 2 


5.6.2.1 [3] 


M 


M 


M 


NG1.M.3 lpo_error_detection 
symmetric MAC service type 






O 


O 


O 


MAC layer procedures: general 


7.9.1 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lp_error_detection symmetric MAC 
service type 3 


5.6.2.1 [3] 


M 


M 


M 


Single-subfield protected format 


6.2.1.3.4 
[3] 


M 


M 


M 



6.13 Application feature to procedure mapping 

The Application feature to procedure mapping of EN 300 444 (GAP) [13], clause 6.8.3 shall apply. 

6.14 General requirements 

6.1 4.1 Network (NWK) layer message contents 

All reserved single bits shall be set to 0. 

6.14.2 Transaction identifier 

The transaction identifier value for a CC call shall always get assigned the lowest available free number. 

6.14.3 Length of a Network (NWK) layer message 

PP and the FP shall be capable of receiving and processing NWK layer messages of at least 63 octets long. All 
mandatory information elements as defined in the present document shall be included in the first 63 octets. 

This requires only one DLC segment to be supported as mandatory. The DLC shall convey the first segment of a layer 3 
message to the NWK layer. Additional segments of a layer 3 message may be discarded by the receiving side, 
(see clause 9.2.3 of EN 300 444 [13]). 
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6.1 4.4 Handling of error and exception conditions 

If a MM message, requesting initiation of a MM procedure, is received in a CC state where the receiving entity is not 
required to support it and does not support it, this message shall be ignored. 

Whenever an unexpected CC message, except {CC-RELEASE} or {CC-RELEASE-COM}, or an unrecognized 
message is received in any CC state, the message shall be ignored. 

When a message other than {CC-SETUP}, {CC-RELEASE} or {CC-RELEASE-COM} is received which has one or 
more mandatory information elements missing or with invalid content, the normal release procedure as described in 
clause 8.7 shall be invoked. 

EN 300 175-5 [5], clause 17.6.4 shall also apply to mandatory information elements in MM messages with a length 
exceeding the allowed maximum value. 

The usage of a reserved value in an information element field shall not by itself constitute an error. The receiver of such 
a value shall process the value if it understands it or shall ignore it otherwise. 

In all other cases the rules and order of precedence specified in EN 300 175-5 [5], clause 17, shall be obeyed. 

6.1 4.5 Generic Access Profile (GAP) default setup attributes 

The «IWU-ATTRIBUTES» and «CALL-ATTRIBUTES» information elements are not required to be understood 
by a "GAP" equipment. The values, as stated in EN 300 175-5 [5], annex E shall be considered as default. The value "1" 
of the field <Network layer attributes> in «CALL-ATTRIBUTES» shall be interpreted as indicating "Generic 
Access Profile (GAP)". 

6.14.6 Coexistence of Mobility Management (MM) and Call Control (CC) 
procedures 

Table 12 below describes whether a MM procedure is supported in any CC state or whether a restriction applies. The 
restriction has been made in order to limit the complexity of the receiving side so that it is not mandated to understand 
MM messages in all CC states for the purpose of achieving inter-operability. 

Table 12: Support of MM procedures in CC states 



Procedure 


Mandatory support in CC state 


Identification of PT 


All states 


Authentication of FT 


All states 


Authentication of PT 


All states 


Authentication of user 


All states 


Location registration 


All states 


Location update 


All states 


Obtaining access rights 


T(F)-00 


FT terminating access rights 


F(T)-00, T-01,T-10 


Key allocation 


F(T)-00 


Cipher-switching initiated by FT 


All states 


Cipher switching initiated by PT 


All states 



The CC and MM entities may work independently one from the other. If a FT decides to perform a MM procedure prior 
to proceeding with a PT initiated CC procedure, the FT has the rights to restart the CC timers in the PT to prevent the 
CC state machine from waiting on a response delayed because of the MM procedure execution. For this purpose the FT 
may send a {CC-NOTIFY} message. The support of this message is mandatory for the PT and optional for the FT. The 
{CC-NOTIFY} shall include the «TIMER-RESTART» information element. 

6.1 4.7 Coding rules for information elements 

For mandatory information elements, at least the first octet within any octet group shall be present. It is not permitted to 
use the information element field <Length of Contents> to omit an octet group. However, if explicitly stated a 
mandatory information element may contain zero length contents. 
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7 Procedure description 



The following clauses define the process mandatory procedures which are in the scope of the New Generation DECT 
wideband speech. Each procedure (if appropriate) is divided into three parts: 

a) normal (i.e. successful) case(s). This part defines the functions and respective protocol element values in 
normal operation; 

b) associated procedure(s). This is an integral part of the actual procedure (if defined in the present document), 
i.e. if a procedure is being declared to be supported, the respective entity shall also support the associated 
procedures, e.g. timer management, in the clause following the description of the normal case; 

c) exceptional case(s). This is an integral part of the actual procedure (if defined in the present document), i.e. if a 
procedure is being declared to be supported, the respective entity shall also support the exception handling 
defined in the clause following the description of the normal case. 

All protocol elements listed in the following clauses are process mandatory, i.e. the FT and PT depending on their role 
in the procedure shall send or shall receive and process the relevant protocol elements as listed in the respective tables if 
not explicitly stated as being optional. 

The primitives used in procedure descriptions are defined only for the purpose of describing layer-to-layer interactions. 
The primitives are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The primitive definitions have no normative significance. 

7.1 Generic Access Profile (GAP) Backward compatibility with 
DECT standard 

7.1 .1 New Generation DECT Fixed Part (FP) requirement 

The FP shall support the GAP standard procedures (full slot and ITU-T Recommendation G.726 [15]). In other words, it 
shall inter-operate with a GAP compliant PP. 

7.1 .2 New Generation DECT Portable Part (PP) registered on standard 
FP 

The PP shall use the GAP standard procedures (full slot and ITU-T Recommendation G.726 [15]) in front of standard 
FP. 

7.2 Generic Access Profile (GAP) procedures 

Unless otherwise noted, all procedures defined in GAP [13] are automatically applicable to New Generation DECT 
wideband speech. Therefore New Generation DECT wideband speech can be considered an extension of GAP. 

The following clauses describe the additional procedures specific for New Generation DECT wideband speech. 

7.3 Network (NWK) layer procedures 

This clause specifies the additional NWK layer procedures, messages and information elements required in 
New Generation DECT wideband speech not described in GAP [13], or incorporating modifications to the GAP 
specification. 

This profile does not prevent any PT or FT from transmitting or receiving and processing any other NWK layer 
message or information element not specified in the profile. A PT or FT receiving an unsupported NWK layer message 
or information element, which it does not recognize, shall ignore it, as specified in EN 300 175-5 [5], clause 17. 
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7.3.1 Exchange of codec list during registration and location registration 

Equipment supporting New Generation DECT wideband speech shall add the IE « CODEC-LIST» indicating the 
supported codecs in the following messages: 

{ACCESS-RIGHTS-REQUEST}, {ACCESS -RIGHTS -ACCEPT} 

{ LOCATE-REQUEST } , { LOCATE- ACCEPT } 

The IE « CODEC -LIST» shall contain at least ITU-T Recommendation G.722 [17] and 
ITU-T Recommendation G.726 [15] codecs. 

7.3.2 Basic service wideband speech and default attributes 

The attribute "wideband speech default" in Information Element «Basic Service» indicates that the default setup 
attributes for wideband speech shall be valid as indicated in annex E.2 of EN 300 175-5 [5], and that the mechanism for 
codec negotiation as described in clause 7.2.3 of the present document are valid. 

7.3.3 Codec Negotiation during call establishment 

Equipment supporting New Generation DECT wideband voice shall support the codec negotiation as described in the 
following. 

A CC-SETUP that offers more codecs than ITU-T Recommendation G.726 [15] shall contain the basic service 
"wideband speech default setup attributes", instead of the basic service "basic speech default setup attributes". 

The IE «CODEC-LIST» may be added in CC-SETUP if a new list of codec is needed on a call by call basis. This 
may be useful when requesting a new codec (codec different from the location/registration phase) or changing the 
priorities within the list of codecs. The IE « CODEC-LIST» shall contain at least 
ITU-T Recommendation G.722 [17] and ITU-T Recommendation G.726 [15] codecs. 

Sending the IE «CODEC-LIST» in CC-SETUP is not necessary in case the most recent list sent during 
registration/location registration is still the valid one. 

The receiving side chooses the codec in a response message, which does not have to be the first response message. The 
codec has at latest to be chosen in a CC-INFO that connects the U-Plane using the IE «PROGRESS-INDICATOR» 
or with CC-CONNECT. The response message which chooses the codec uses the same IE «CODEC-LIST», but only 
one codec shall be in the list. 

Setup parameters which are not mentioned in the IE «CODEC-LIST» shall have default values as given in 
EN 300 175-5 [5] of this document. The IEs «IWU-attributes», «CALL-attributes» and 
«CONNECTION-attributes» shall not be used in the CC-SETUP or in the response message. 

After a codec was chosen, the call initiating side initiates a slot type modification at MAC layer if necessary. 

In the case where the slot type modification is necessary and fails, the initiating side shall switch to a mandatory codec 
supporting the current slot format and indicate so by sending {IWU-INFO} including the IE «CODEC-LIST» with 
the required codec. On receiving this message, the receiving side shall also switch back to the required codec and 
indicate so by sending {IWU-INFO} including the IE «CODEC-LIST» with the required codec. 

In the case where no slot type modification is necessary or the slot type modification is successful, {IWU-INFO} 
messages are not exchanged. 
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PP 



FP 



CC-SETUP 






«Basic Service=88» 






«Codec-List» * 


response message 






«Codec-List=chosen codec» 





Figure 4: Codec Negotiation during call setup 

7.3.4 Codec Change 

Equipment supporting New Generation DECT wideband voice shall support the codec change as described in the 
following during call establishment after the codec negotiation is finished and in CC-state ACTIVE. 

To switch the codec the initiating side sends a CC-SER VICE-CHANGE including the IE«CODEC-LIST» and the 
IE«SERVICE-CHANGE-INFO». 

The IE «CODEC-LIST» shall contain only one codec. 

The IE «SERVICE-CHANGE-INFO» shall indicate that an audio codec change is attempted and that the sending 
side is master of the change. 

The receiving side shall either accept or reject the change. 

Both CC-SERVICE-ACCEPT and CC-SERVICE-REJECT shall not contain the IE «CODEC-LIST». 

In case the change is accepted, the initiator of the service change also initiates a slot type modification at MAC layer if 
necessary. 

Having switched to the new codec and performed slot type modification if necessary, both sides shall indicate so by 
sending {IWU-INFO} including the IE «CODEC-LIST» with the new codec. 

In case the slot type modification fails the initiating side shall switch back to the old codec and indicate so by sending 
{IWU-INFO} including the IE «CODEC-LIST» with the old codec. On receiving this message, the receiving side 
shall also switch back to the old codec and indicate so by sending {IWU-INFO} including the IE «CODEC-LIST» 
with the old codec. 

Each side shall mute its receiving path at sending/receiving CC-SERVICE-ACCEPT. 

Receiving {IWU-INFO} shall be a trigger for each side that it may unmute its receiving path. 

{IWU-INFO} shall also be sent in case the service change is performed before CONNECT, although the U-Plane will 
not be connected before CONNECT. 

The service change for audio codec change is always followed with sending {IWU-INFO} from both sides. A new 
service change shall not be initiated until both sides have sent {IWU-INFO}. 



7.3.4.1 



Service change info 



In order to change the codec, the value "Audio Change codec" (see clause 7.7.38 of EN 300 175-5 [5]) shall be inserted 
in the IE «Service Change Info». 
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7.3.5 Slot type modification 



If the codec change requires a modification in the slot type, the MAC slot change procedure shall be executed as 
described in EN 300 175-3 [3], clause 10.3.2. 

The initiating side of the Network Layer procedure shall also initiate the slot type modification at MAC layer in order to 
change the audio codec. 



7.3.5.1 



Failure of slot type modification 



On failure of the slot type modification the initiating side shall not release the call but switch back to the previously 
active codec and indicate so to the receiving side by sending {IWU-INFO} including the IE «CODEC-LIST» with 
the old codec. On receiving this message, the receiving side shall also switch back to the old codec and indicate so by 
sending {IWU-INFO} including the IE «CODEC-LIST» with the old codec. 

This can happen both after Service Negotiation and after Service Change. After Service Change the previously active 
codec shall be restored. After Service Negotiation a mandatory codec shall be used fitting to the previous slot format. 

7.3.6 Internal call setup 

NOTE 1: This procedure description replaces clause 8.18 of GAP [13]. 

The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

For the initiation of this procedure the "outgoing call request" procedure defined in GAP (clause 8.2 of [13]) shall be 
used, with the following replacement to the {CC-SETUP} message: 

Table 13: Values used within the outgoing {CC-SETUP} message for internal call 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Basic service» 


<Call class> 


9 


Internal call 



For the termination of this procedure the "incoming call request" procedure defined in GAP (clause 8.12 of [13]) shall 
be used. 

However, if the Portable Part is an NG DECT PP, the NG DECT FP shall use the following replacement to the 
{CC-SETUP} message: 

Table 14: Values used within the incoming {CC-SETUP} message to a 
New Generation DECT PP for internal call 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Basic service» 


<Call class> 


9 


Internal call 



NOTE 2: A New Generation DECT PP is identified by the support in the "Terminal capability indication" 
procedure (clause 7.3.5). 

For backward compatibility reasons, New Generation DECT FPs shall use the "external call" call class if the PP is a 
GAP PP. 

NOTE 3: A New Generation DECT PP is identified by the support in the "Terminal capability indication" 
procedure (clause 7.3.5). 
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7.3.7 Terminal capability indication 

NOTE: This procedure description replaces clause 8.17 of GAP [13]. 

The PP shall be able to send the «Terminal capability» information element and the FP shall be able to receive it at 
least in {ACCESS-RIGHTS-REQUEST} and when location registration is supported in the {LOCATE-REQUEST}. 
The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

Table 15: Values used within the «TERMINAL CAPABILITY» information element 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal 
capability» 








<Tone capability> 


All 




<Display capability> 


All 


If PT supports feature (N.24) it shall 
indicate in this field value which is 
equal to or higher than 2 


<Profile indicator 1> 


"xxxxxl x"B 


GAP and/or PAP supported 


<Profile indicator_7> 


"xxxxx1x"B 


New Generation DECT Wideband 
speech supported 


<Control codes> 


All 


If PT supports feature (N.25) it shall 
indicate in this field value which is 
equal to or higher than 2 



The capabilities in table 16 shall be assumed as default if the following fields in the «TERMINAL CAPABILITY» 
information element are not present. 

Table 16: Values assumed as terminal capabilities 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal 
capability» 








<Echo parameters> 


1 


Minimum Telephone Coupling Loss 
(TCL) (> 34 dB) 


<N-REJ> 


1 


No noise rejection 


<A-VOL> 


1 


No PP adaptive volume control 


<Slot type capability> 


"xxx1x1x"B 


Full slot and Long slot (j=640) 
supported 



No echoing of characters is allowed in the FT and therefore the PT would be responsible for displaying dialled digits. 
All display information from the FT would be assumed to be additional information that the PT shall display in 
addition. The PT shall logically separate display information originating at the FT and PT. This could be achieved, for 
example, by one physical display and two logical displays or two physical displays and two logical displays. The key 
point is that display characters from the PT and FT shall not be simultaneously interleaved/mixed on the same physical 
display. 

7.4 Implementation examples of specific procedures 

For detailed examples please refer to the informative Annex D. These diagrams are strongly recommended to be used as 
implementation guidelines as they are best practice cases and respect all mandatory requirements of the current 
standard. 

7.5 Data Link Control (DLC) layer procedures 

This clause specifies the additional DLC layer procedures, messages and information elements required in New 
Generation DECT wideband speech not described in GAP [13], or incorporating modifications to the GAP 
specification. 
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7.5.1 FU1 frame operation 



The procedure shall be performed as defined in EN 300 175-4 [4], clauses 12.1 and 12.2. The following text together 
with the associated clauses define the mandatory requirements with regard to the present document. 



PT 



FT 



FU1 frame 



Figure 5: Sending a FU1 frame 

NOTE: The case when FT initiates differs only in the notations. 

The length of a FU1 frame will be k = 40 (full slot) for 32 kbit/s services and k = 80 octets (long slot) for 64 kbit/s 
services. 

One complete frame shall be submitted to/from MAC layer included in a MAC_CO_DATA-req(ind) primitive. 

7.6 Medium Access Control (MAC) layer procedures 

This clause specifies the additional MAC layer procedures, messages and information elements required in New 
Generation DECT wideband speech not described in GAP [13], or incorporating modifications to the GAP 
specification. 

7.6.1 MAC services 

The FT and PT shall support I N _minimum_delay symmetric service as defined in EN 300 175-3 [3], clause 5.6.2.1 and 
clause 10.8.3.1. 

The FT and PT may support I N _normal_delay symmetric service as defined in EN 300 175-3 [3], clause 5.6.2.1 and 
clause 10.8.3.2. 

The FT and PT may support I P Q_error_detection symmetric service as defined in EN 300 175-3 [3], clause 5.6.2.1 and 
clause 10.8.3.2. 

7.6.2 Frame formats and multiplexers 

The FT and PT shall support the following frame formats: 

• D-field mapping for the full slot structure (physical packet P32), as defined in EN 300 175-3 [3], 
clause 6.2.1.1.2. 

• D-field mapping for the variable slot structure (physical packet POOj), as defined in EN 300 175-3 [3], 
clause 6.2.1.1.3, with aj value of j = 640. 

The FT and PT may support frame format as follows: 

• D-field mapping for the variable slot structure (physical packet POOj), as defined in EN 300 175-3 [3], 
clause 6.2.1.1.3, with a j value of j = 672. 

• D-field mapping for the double slot structure (physical packet P80), as defined in EN 300 175-3 [3], 
clause 6.2.1.1.1. 

The FT and PT shall support A-field mapping A-MAP. 
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The FT and PT shall understand all A field tail identifications (aO, al and a2) in the header field as defined in 
EN 300 175-3 [3], clauses 6.2.1.2 and 7.1.2. 

The FT and PT shall support the following B-field field identifications (a4, a5 and a6) as defined in EN 300 175-3 [3], 
clause 7.1.4: 

• U-type: In, "000"B. 

• No B-field, "111" B (shall only be used for dummy bearers). 

• Long slot required, "101"B. 

The FT and PT shall support T-MUX as defined in EN 300 175-3 [3], clause 6.2.2.1. 

The FT and PT shall support B-field multiplex E/U MUX type U32a and U64a. 

The FT and PT shall support scrambling as defined in EN 300 175-3 [3], clause 6.2.4. 

The FT and PT shall provide R-CRC generation and checking as defined in EN 300 175-3 [3], clause 6.2.5.2. The FT 
and PT shall provide X-CRC generation and checking as defined in EN 300 175-3 [3], clauses 6.2.5.3 and 6.2.5.4. 

The PT shall support the normal duty cycle idle_locked mode as defined in EN 300 175-3 [3], clauses 11.3 and 4.3.1. 

The FT and PT shall support primary scan procedure as defined in EN 300 175-3 [3], clause 1 1.8. 

All requirements specified in EN 300 444 (GAP) [13], clause 10, shall apply. 

7.7 Physical layer (PHL) requirements 

7.7.1 Modulation 

The FT and PT shall support 2 level Gaussian Frequency Shift Keying (GFSK) modulation as defined by 

EN 300 175-2 [2] clause 5. 

7.7.2 Slot type (Physical packets) 

The FT and PT shall support Physical packet P32 (full slot) as defined by EN 300 175-2 [2] clause 4.4.2. 

The FT and PT shall support Physical packet POOj (variable slot) as defined by EN 300 175-2 [2] clause 4.4.3, with a j 
value of j = 640. 

The FT and PT may support Physical packet POOj (variable slot) as defined by EN 300 175-2 [2] clause 4.4.3, with a j 
value of j = 672. 

The FT and PT may support Physical packet P80 (double slot) as defined by EN 300 175-2 [2] clause 4.4.4. 

All requirements specified in EN 300 444 (GAP) [13], clause 11, shall apply. 

All requirements specified in EN 300 175-2 [2], and EN 301 406 [10] (replacing TBR 006 [25]) for 2 level GFSK 
modulation shall apply. 

7.8 Requirements regarding the speech transmission 
7.8.1 General 

The applicable requirements specified in EN 300 175-8 [8] and EN 300 176-2 [9] (previously covered by 
TBR 010 [26]) shall be applied. 
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7.8.2 Speech codecs 



The FT and PT shall support ITU-T Recommendation G.726 [15] ADPCM narrow band codec [15], operating at 
32 kbit/s rate, as defined by EN 300 175-8 [8] clause 5.1. 

The FT and PT shall ITU-T Recommendation G.722 wideband SB-ADPCM 7 kHz codec [17], operating at 64 kbit/s 
rate, as defined by EN 300 175-8 [8] clause 5.3. 

The FT and PT may support ITU-T Recommendation G.71 1 PCM narrow band codec [16], operating at 64 kbit/s rate, 
as defined by EN 300 175-8 [8] clause 5.2. 

The FT and PT may support ITU-T Recommendation G. 729.1 wideband codec [18], operating at 32 kbit/s rate, as 
defined by EN 300 175-8 [8] clause 5.4. 

The FT and PT may support MPEG-4 ER AAC-LD codec [20], operating at 32 kbit/s or 64 kbit/s rate, as defined by 
EN 300 175-8 [8] clause 5.5. 

7.8.3 Audio performance requirements 

7.8.3.1 Audio performance requirements for narrowband 3,1 kHz speech 

New Generation DECT handsets shall fulfil the audio performance requirements described in EN 300 175-8 [8], 
clause 7. 

7.8.3.2 Audio performance requirements for wideband 7 kHz speech 

New Generation DECT handsets shall fulfil the audio performance requirements described in 
ITU-T Recommendation P.31 1 [21], as described in EN 300 175-8 [8], clause 9. 

7.9 Management procedures 

All procedures described in GAP [13] clause 13 shall be supported. 

7.10 Application procedures 

All procedures described in GAP [13] clause 14 shall be supported. 
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Annex A (informative): 
Audio codecs 

A.1 Speech and audio coding 
A. 1.1 Overview 

The basic codec for speech in the DECT standard is the "Adaptive Differential Pulse Code Modulation" (ADPCM) with 
32 kbit/s as defined in ITU-T Recommendation G.726 [15]. It is of low complexity, offers a bandwidth of 3,1 kHz, 
introduces a very low delay of 0,125 ms and a quality slightly below the PSTN quality 
(ITU-T Recommendation G.71 1 [16] encoding) at 64 kbit/s. 

Increasing the bandwidth from narrow band (300 Hz to 3 400Hz) to at least to 150 Hz to 7 000 Hz range ("wide band") 
will allow to increase decisively the speech quality: voice better encoded on all its frequencies, with a feeling of more 
transparent communication, a greatly improved sensation of presence and an increased intelligibility and listening 
comfort. 

The following table reviews some speech and audio codecs. 

Table 17: Codec overview 





Type 


Bandwidth 
[kHz] 


Sampling rate 
[kHz] 


Bit rate 
[kbit/s] 


Frame 
[ms] 


ITU-T Recommendation 
G.711 [16] 


LOG PCM 


0,3 to 3,4 


8 


64 


0,125 


ITU-T Recommendation 
G.726 [15] 


ADPCM 


0,3 to 3,4 


8 


16,24,32,40 


0,125 


ITU-T Recommendation 
G.722[17] 


Sub-Band 
ADPCM 


0,05 to 7 


16 


64, 56, 48 


0,125 


ITU-T Recommendation 
G.729.1 [18] 


EV-CELP 

Time Domain 

Bandwidth 

Extension 

(TDBWE) 

Transform 

Coding (MDCT) 


0,05 to 7 


16 


8, 12, 14, 16, 18, 
20, 22, 24, 26, 28, 
30,32 


20 


ISO/I EC 14496-3 [19] 


MPEG-4 ER 
AAC-LD 

Advanced Audio 
Coding Low 
Delay 


up to 20 


up to 48 


range of bit rates 
(around 24 to 96) 


10 to 20 

(depends 

on 

sampling 

rate) 
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A.1 .2 Narrow band speech coding 



ITU-T Recommendation G.726 narrow band codec [15] is mandatory for New Generation DECT in order to ensure 
interoperability with existing DECT systems. 

ITU-T Recommendation G.71 1 narrow band codec [16] is optional for New Generation DECT in order to improve the 
quality of narrow band communications: slightly higher intrinsic voice quality, better robustness to transmission errors 
and no transcoding for PSTN calls. 

Table 18: ITU-T Narrow band Speech codec for New Generation DECT 



Standard 


ITU- 

T Recommendation 

G.726 


ITU- 

T Recommendation 

G.711 




ADPCM 


LOG PCM 


Date 


1990 


1972 


Bandwidth 


300 Hz to 3 400 kHz 


300 Hz to- 3 400 kHz 


Sampling rate 


8 kHz 


8 kHz 


Bit rate(kbit/s) 


16, 24, 32, 40 


64 


Embedded Scalability 


No 


No 


Type 


ADPCM 


LOG PCM 


Frame size 


0, 125 ms 


0, 125 ms 


Algorithmic Delay 


0, 125 ms 


0, 125 ms 


Complexity 


12 MIPS 


0,01 MIPS 


RAM (kBytes) 


1 


«0 
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A.1 .3 Wideband Speech coding 



ITU-T Recommendation G.722 codec [17] is chosen as mandatory wideband codec for New Generation DECT in order 
to greatly increase the voice quality by extending the bandwidth from narrow band to wideband. 

ITU-T Recommendation G.722 [17] provides a high wideband quality at a bit rate of 64 kbit/s with low complexity and 
very low delay. 

In addition, ITU-T Recommendation G.729.1 codec [18] is recommended as an optional codec for wideband speech to 
provide even higher wideband quality and better robustness to frames/packets losses than 

ITU-T Recommendation G.722 [17] at much lower dynamically adaptable bit rates. This allows a better transport 
efficiency on the network side and over the DECT air interface (fits in one single current DECT slot). In addition, it is 
seamless interoperable with largely deployed ITU-T Recommendation G.729 based VoIP networks and terminals. 
ITU-T Recommendation G.729.1 [18] encodes signals in frames of 20 ms. It is a scalable codec operating at bitrates of 
8 kbit/s and from 12 kbit/s to 32 kbit/s per steps of 2 kbit/s, both in narrowband or in wideband from 14 kbit/s. 

Table 19: ITU-T Wideband Speech codec for New Generation DECT 



Standard 


ITU-T Recommendation G.722 


ITU-T Recommendation G.729.1 




SB-ADPCM 


G.729 EV 


Date 


1988 


2006 


Bandwidth 


50 Hz to 
7 kHz 


50 Hz to 4 kHz 

50 Hz to 7 kHz (bit rates > 14 

kbit/s) 


Sampling rate 


16 kHz 


8kHz/ 16kHz 


Bit rate(kbit/s) 


64, 56, 48 


8, 12, 14, 16, 18, 20, 22, 24, 26, 
28, 30, 32 


Embedded 
Scalability 


Yes 


Yes (interoperable at 8 kbit/s with 
G.729) 


Type 


Sub-Band ADPCM 


EV-CELP 

Time Domain Bandwidth Extension 

(TDBWE) 

Transform Coding (MDCT) 


Frame size 


0, 125 ms 


20 ms 


Algorithmic Delay 


1,625 ms 


48,9375 ms 


Complexity 


10 MIPS 


35,8 WMOPS based on new 

STL2005 

(34,7 WMOPS based on STL2000) 


RAM (kBytes) 


1 


17,4 



PLC (Packet loss Concealment) ITU-T Recommendation G.722 [17] Appendix III and IV (NG1.S7): Appendices 
III and IV describe packet loss concealment solutions extending ITU-T Recommendation G.722 [17] decoder. These 
algorithms may be optionally implemented to improve voice quality in degraded transmission conditions where 
packets/frames may be lost (in the IP network or on the DECT air interface). Both appendices meet the same quality 
requirements but address two different quality/complexity trade offs: 

• Appendix III aims at maximizing the robustness at a price of additional complexity (+0,1 to 0,2 MOS in 
comparison with appendix IV in degraded conditions ). 

• Appendix IV proposes an optimized complexity/quality trade off with almost no additional complexity 
compared with ITU-T Recommendation G.722 [17] normal decoding (0,07 WMOPS). 

Since ITU-T Recommendation G.722 [17] does not incorporate any mechanism to cope with lost frames/packets, the 
use of a PLC algorithm is strongly recommended to avoid annoying effects in case of packet/frame losses. 

NOTE: ITU-T Recommendation G.729.1 [18] already incorporates a high efficiency packet loss concealment 
mechanism. 



ETSI 



39 



ETSI TS 102 527-1 V1.1.1 (2007-04) 



Table 20: ITU-T Recommendation G.722 [17] PLC Appendices for New Generation DECT 



PLC 


Appendix III 


Appendix IV 


Date 


2006 


2006 


Type 


Full band waveform extrapolation 
Re-encoding and signal monitoring, 
re-phasing and time warping 


Split-band waveform 

extrapolation 

Partial state reset, cross fading 


Packetization size/ms 






Complexity 

Observed Worst Case in 

WMOPS (based on STL2005) 


5,87 WMOPS (10 ms packets) 
5,60 WMOPS (20 ms packets) 


3, 18 WMOPS (10 ms packets) 
3, 15 WMOPS (20 ms packets) 


Total RAM (10 ms packets) 

(Static + Scratch) 

Total RAM (20 ms packets) 

(Static + Scratch) 

In 16 bits Words 


2 184 (10 ms packets) 
(1 118 + 826) 
1 944 (20 ms packets) 
(1 118+ 1066) 


1 659 (10 ms packets) 
(967 + 692) 
1 659 (20 ms packets) 
(967 + 963) 


Program ROM 

(in number of basic-ops and 

function calls) 


2410 


1 061 


Table ROM 

(in 16 bits Words 


1 414 


882 



To handle several codecs (at least ITU-T Recommendation G.726 [15] and ITU-T Recommendation G.722 [17]), New 
Generation DECT will support a codec selection and switching mechanism. This may consequently allow the use of 
other codecs that could be recommended in next releases as additional optional codecs according to future application 
or interoperability needs. 



A.1.4 



Super-wideband speech and audio coding 



The MPEG-4 ER AAC-LD 64 kbit/s audio codec [20] is recommended as an optional codec for super-wideband speech. 
In order to provide high quality for music streaming or other multimedia applications mixing speech and music, the 
bandwidth can be further extended to superwideband (50 Hz to 14 kHz) and above (up to full audio bandwidth 
(20 Hz to 20 000 Hz). The codec may be also suitable for wideband speech. 

MPEG-4 ER AAC-LD is designed for high quality communication application including all kind of audio signals e.g. 
speech and music. It provides an audio bandwidth of 14 kHz at a bitrate of 64 kbit/s. MPEG 4 ER AAC-LD is 
standardized in ISO/IEC 14496-3 [20]. The frame size is 10 ms and the algorithmic delay 20 ms. It may also be 
optionally used in 32 kbit/s mode. It provides a recommended bandwidth of 1 1,5 kHz. The frame size is 20 ms and the 
algorithmic delay 40 ms. 

Table 21 : MPEG-4 ER AAC-LD Audio codec for NG DECT 



Standard 


MPEG-4 ER AAC- LD 
32 kbit/s 


MPEG-4 ER AAC-LD 
64 kbit/s 








Date 


2000/2006 


2000/2006 


recommended Bandwidth 


11,5 kHz 


14 kHz 


Sampling rate 


24 kHz 


48 kHz 


Bit rate(kbit/s) 


32 


64 


Embedded Scalability 


no 


no 


Type 


perceptual audio 
codec 


perceptual audio codec 


Frame size 


20 ms ( 480 samples ) 


10 ms ( 480 samples ) 


Algorithmic Delay 


40 ms 


20 ms 


example Complexity 


-13 MIPS (encoder) 
-5 MIPS (decoder) 


-25 MIPS (encoder) 
-10 MIPS (decoder) 


example RAM (kBytes) 


-28 kbyte (encoder) 
-13 kbyte (decoder) 
10 Buffer not included 


-28 kbyte (encoder) 
-13 kbyte (decoder) 
10 Buffer not included 



As for wideband speech codec, the codec selection and switching mechanism may allow the use of other configurations 
or other optional super- wideband speech and audio codecs according to the applications or interoperability needs. 
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Annex B (normative): 

Audio patterns to indicate IP packet losses on the DECT link 

B.1 Audio patterns to indicate IP packet losses. 

The following annex is applicable for: 

• New Generation DECT FP connected to a VoIP network (directly or through a gateway) with audio frames 
coming from the VoIP network decoded in the PT (no transcoding done between the network and the DECT 
link). 



B.1 .1 Insertion of audio patterns 



Upon detection of a packet loss or a corrupted IP packet, the FP shall insert an appropriate audio pattern on the DECT 
link in direction of the Portable part. 

These patterns may be repeated as many times as necessary on the DECT link to replace the faulty IP packet. For 
example if a 20 ms RTP VoIP packet is lost. The pattern shall be inserted twice on the DECT link. 

B.1 .2 Reception of audio patterns 

Upon reception of these patterns in the PT: 

• If a PLC is available on the PT with the current activated codec, the PT should activate it. 

• If no PLC is available on the PT, the PT should decode this pattern as normal audio frame in the decoder. 

However, it is recommended to use standardized PLC mechanism in order to improve audio robustness to packet losses. 

It is not recommended to use these patterns in the PT to FT direction as the PT should always be able to provide correct 
audio frames as soon as the U-plane is established on the DECT link. 

B.1 .3 Contents of the audio patterns 

The following patterns were chosen because: 

• They correspond to 10 ms of audio decoded signal (20 ms for 20 ms audio framed codec). 

• They generate a very low energy decoded signal if no PLC mechanism is available on the terminal. 

Their occurrence in normal audio encoded bitstream is quite impossible. 

For MPEG-4 ER AAC-LD, the pattern is a standard conform MPEG-4 ER AAC-LD frame. If no PLC mechanism is 
available on the terminal side, the pattern forces the decoder to fade out smoothly within 10 ms (20 ms at 32 kbps). The 
same pattern can be used for both, the 64 kbit/s and 32 kbit/s service. The transport format is a MPEG-4 Access Unit. 
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B.1 .4 Packet loss patterns for ITU-T Recommendation G.722 

ITU-T Recommendation G.722 [17] law packet loss pattern. 640 bits. To be inserted in 1 long slot. 

/* Pattern is OxFF (repeated 80 times) 7 
Pattern[80] ={ 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF}; 

B.1 .5 Packet loss patterns for ITU-T Recommendation G.71 1 

ITU-T Recommendation G.711 [16] law packet loss. 640 bits. To be inserted in 1 long slot. 

/* Pattern is 0xD5 (repeated 24 times), 0x55 (repeated 32 times), 0xD5 (repeated 24 times) 7 
Pattern[80] ={ 

0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 

0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 

0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 

0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 

0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 

0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 

0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 

0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 

0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 

0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5, 0xD5}; 

ITU-T Recommendation G.711 [16] law packet loss. 640 bits. To be inserted in 1 long slot. 

/* Pattern is OxFF (repeated 24 times), 0x7F (repeated 32 times), OxFF (repeated 24 times) 7 

Pattern[80] ={ 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 
OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 
OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 
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0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 

0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 

0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 

0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, 

OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF, OxFF}; 

B.1 .6 Packet loss patterns for ITU-T Recommendation G.726 

ITU-T Recommendation G.726 [15]. 

No pattern is proposed for the reason that a transcoding is done in the Fixed part, so the PLC is not done in the PP. 

B.1 .7 Packet loss patterns for ITU-T Recommendation G. 729.1 

ITU-T Recommendation G.729.1 [18] packet loss. 640 bits. To be inserted in 2 full slots. Audio frames are 20ms. 

The payload format described in Annex C.l "transport of the ITU-T Recommendation G.729.1 [18] audio frame in full- 
slot mode" shall be used. The following patterns must replace the faulty packets in the coded bitstream in case of packet 
loss: 

First full slot 

In the first full slot, bad frame indicator is set BFI=1, First frame part: FPA1=0 FPA2=0, Parity even is set PA=1. 
Pattern[40] ={ in full slotl 

0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 

Second full slot 

In the second full slot, bad frame indicator is set BFI=1, second frame part: FPA1=0 FPA2=1, Parity even is not set 
PA=0. 

Pattern[40] ={ in full slot2 

0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 
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B.1 .8 Packet loss patterns for MPEG-4 ER AAC-LD 

MPEG-4 ER AAC-LD, 64 kbit/s 

MPEG-4 ER AAC-LD packet loss pattern. 640 bits. To be inserted in 1 long slot (64 kbit/s). Audio frames are 10 ms. 
Pattern[80]={ 

0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x32, 
0x92, OxOA, 0x6A, 0x2A, OxFA, 0x62, 0x7A, 0x9A, 0x9D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x28, 0x00 

}; 

MPEG-4 ER AAC-LD, 32 kbit/s 

MPEG-4 ER AAC-LD packet loss pattern. 640 bits. To be inserted in 2 full slots (32 kbit/s). Audio frames are 20 ms. 
First full slot 
Pattern[40]={in full slotl 

0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x32, 
0x92, OxOA, 0x6A, 0x2A, OxFA, 0x62, 0x7A, 0x9A, 0x9D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D 

}; 

Second full slot 

Pattern[40]={in full slot2 

0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 
0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x2D, 0x28, 0x00 

}; 
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Annex C (normative): 

Configuration signalling for specific codecs 

C.1 MPEG-4 ER AAC-LD configuration signalling 

If the MPEG-4 ER AAC-LD voice service is used as a communication service, some out of band signalling increases 
the interoperability between FP and the IP world. Therefore the following two «IWU to IWU» elements shall be 
used to signal the available capabilities. The first «IWU to IWU» element shall be used to signal the supported 
capabilities of the device (MPEG4CapabilityElement) and the second element shall be used to signal the selected 
configuration (MPEG4ConfigurationElement) . 

Both elements contain level and transport format information whereas AudioSpecificConfig (ASC) is transmitted only 
within the MPEG4ConfigurationElement. 

• Level: Used Low Delay AAC Profile level. 

• Transport format: RFC3640 [21] transmits plain MPEG-4 access units whereas in RFC3016 [23] LATM 
transport format is used. Both formats can be converted into each other. To avoid the conversion process 
transmission of both formats over the New Generation DECT link is possible. 

• AudioSpecificConfig: The usage of ER tools is signalled within ASC. In packet oriented IP transmission ER 
tools are normally not used up to now. This has to be signalled to the decoder. The AudioSpecificConfig is 
included in the RTP Payload format description RFC 3640 [22]/RFC 3016 [23]. With it, the FP can directly 
transmit the AudioSpecificConfig to the IP world and back to the PP. Thus the transportation of the 
AudioSpecificConfig is possible. 

The «IWU to IWU» Elements has to be transmitted in certain messages if the IE «Codec List» [5] includes 
MPEG-4 ER AAC-LD. The format of both «IWU to IWU» Elements differs only in the occurrence of the 
AudioSpecificConfig. The ASC occurrence depends on the length of the corresponded «IWU TO IWU» Element. 
The length of the MPEG-4 Capability Element is 4 octets while the MPEG4 ConfigurationElement which includes an 
ASC exceeds 4 octets. 

C.1 .1 «IWU to IWU» element to signal the supported 
capabilities (MPEG4CapabilityElement) 

If a new PP is registered at the FP side it is important for both, PP and FP, to get information about the 

MPEG-4 ER AAC-LD capability of the responding part. Therefore it is possible to determine the fitting configuration 

during a call establishment without any further negotiation process. 

The following «IWU to IWU» Element will handle the signalling of the supported capability and shall be used in the 
MM-Messages «LOCATE-REQUEST», «LOCATE-ACCEPT», «ACCESS-RIGHTS-REQUEST», 
«ACCESS-RIGHTS-ACCEPT». 

In case of default configuration according to table C.1, no MPEG4CapabilityElement shall be sent. 

Information element coding: 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 


Octet: 



























« IWU to IWU» (0x77) 


1 




Length of Contents (L) 


2 




1 


S/R 


Protocol Discriminator 

( 0x25 MPEG-4 ER AAC-LD Configuration 

Description ) 


3 




Transport format capability 


MPEG-4 ER AAC-LD Level 
capability 


4 
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The "Transport format capability" field contains the supported transport formats and shall be interpreted as follows: 



Bit: 


8 


7 


6 


5 


Octet 




reserved 


reserved 

(e.g. MPEG-4 LOAS 

AudioPointerStream()) 


MPEG-4 LOAS 
AudioSyncStreamQ 


MPEG-4 Access Units 

(content of 
er_raw_data_block()) 


4 



Whereas MPEG-4 LOAS AudioSyncStream() and MPEG-4 Access Unit capability is mandatory for a New Generation 
DECT device which supports MPEG-4 ER AAC-LD. 

The content of the "MPEG-4 ER AAC-LD Level capability" field describes the supported Low Delay AAC Profile 
level [19]. Higher levels also include the support of lower levels: 

MPEG-4 ER AAC-LD Level capability Coding (Octet 4): 

Bits 4 3 21 Meaning 

reserved for ETSI use 

1 ISO/IEC 14496-3:2005 Low Delay AAC Profile level 1 [19] 

all other values reserved 

Table C.1 Default Coding of MPEG4CapabilityElement 



Octet 


Information Element Field 


Field Value 


4 


MPEG-4 ER AAC-LD Level 
capability 


ISO/IEC 14496-3 [19]:2005 Low 

Delay AAC Profile level 1 

(="0001 "B) 


4 


Transport format capability 


Bit 5 MPEG-4 Access Units = 1 
Bit 6 MPEG-4 LOAS 1 
AudioSyncStreamQ = 1 



C.1 .2 «IWU to IWU» element to signal the used Configuration 
(MPEG4ConfigurationElement) 

During the connection establishment between PP, FP and the IP world, the selected transport format and the selected 
Low Delay AAC Profile level [19] is signalled. Furthermore the transport of the AudioSpecficConfig (detailed 
description can be found in [20]) is used to signal MPEG-4 ER AAC-LD error resilience tools. If the IE 
«Codec List» provides MPEG-4 ER AAC-LD, the following «IWU to IWU» element has to be used in the 
following messages: 

Messages: 

«CC-SETUP», «CC-CONNECT», «CC-INFO», «CC-SETUP-ACK», «CC-CALL-PROC», «CC- 
ALERTING»,«IWU-INFO»,«CC-SERVICE-CHANGE». 

Information element coding: 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 


Octet: 



























« IWU to IWU» (0x77) 


1 




Length of Contents (L) 


2 




1 


S/R 


Protocol Discriminator (0x25 MPEG-4 ER AAC-LD 
Configuration) 


3 




Transport format 


MPEG-4 ER AAC-LD Level 


4 




content of AudioSpecificConfig 


5 












L+2 
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The "Transport format" field contains the selected transport format and should be interpreted as follows: 



Bit: 


8 


7 


6 


5 


Octet 




reserved 


reserved 

(Audio Pointer 

stream) 


MPEG-4 LOAS 
AudioSyncStreamQ 


MPEG-4 Access Units 

(content of 
er_raw_data_block()) 


4 



Whereas only one bit of these fields is set to signal the used transport format. The content of the "MPEG-4 ER AAC- 
LD Level" describes a value indicating which Low Delay AAC Profile Level [19] is used. 

MPEG-4 ER AAC-LD Level Coding (Octet 4): 

Bits 4 3 21 Meaning 

reserved for ETSI use 

1 ISO/IEC 14496-3:2005 Low Delay AAC Profile level 1 [19] 

all other values reserved 

The Octets 5 to L+2 contains the AudioSpecificConfig [20]. 
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Annex D (informative): 

Recommended implementation of procedures 

D.1 Examples of implementation of specific procedures 
D.1.1 General 

In the following clauses, several examples are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows shall always be 
exactly in the described way. 

For example it should remain in the hand of each device whether a service is confirmed at the latest possibility with 
CC_CONNECT or in an earlier message with the consequence that a service negotiation might be more probable. 

Also it should remain in the hand of each base station, whether CALL-PROCEEDING is sent or directly 
CC-CONNECT. 

Also it should remain in the hand of each device, in which situation it establishes a long-slot connection or prefers to 
establish a full-slot connection, perhaps at the risk that connection modification will be more probable. 

Therefore the diagrams can only be used as recommendations. 

The connection of the U-Plane is not marked in the diagrams, but done as usually in DECT with sending/receiving of 
CC-CONNECT for outgoing calls and with sending/receiving CC-CONNECT-ACK for incoming calls. In addition to 
this, the IE «Progress Indicator» can be sent from FP to PP in order to connect the U-Plane. 

Where the diagrams contain "paging for longslot", it should be kept in mind, that the FP are only paging for the 
establishment of the slot type "long slot" in case the PP indicated the support of the corresponding long slot format in 
the terminal capabilities. 



ETSI 



48 



ETSI TS 102 527-1 V1.1.1 (2007-04) 



D.1 .2 Outgoing wideband call 

D.1 .2.1 Outgoing wideband call, no codec list, ITU-T Recommendation 
G.722 chosen 

Use case: User requests a wideband call and the network supports it. 



PP 

_L_ 



FP 



IP-Network 



WBcall initiated 



mac setup -> longslot 



CC-SETUP 



«Basic Service=88» 



CC-CALL-PROC 



CC-CONNECT 



«Codeo-List = G.722» 



INVITE (SDP: G722, PCMA, PCMU,. 



200 OK (SDP: G722) / 183 RINGING (SDP: G722) 



Figure D.1 : Outgoing wideband call, no codec list, ITU-T Recommendation G.722 chosen 

The use of the basic service "wideband speech default setup attributes" implies the offer of the codec -list indicated in 
the last (location) registration or at subscription registration. Since in this example no other Codec List shall be 
indicated, the IE «Codec-List» can be omitted in CC-SETUP. 

In a response message (here CC-CONNECT), the peer entity confirms the chosen service with «Codec-List». 

The following tables are showing the IE codings for this example: 

Table D.1 : Values used within the {CC-SETUP} message 



Information element 


Information 
Element 
Coding 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


« Basic Service » 


e0 88 












« Call class » 


1000 


Normal call setup 






« Basic Service » 


1000 


Wideband speech default setup attributes 



Table D.2: Values used within the {CC-CONNECT} message 



Information element 


Information 
Element Coding 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


«Codec-List» 


7c 04 90 03 00 81 












« Negotiation 
indicator» 










«1st codec identifier» 


0000011 


ITU-T Recommendation G.722 [17] 






« MAC service » 


0000 


In min delay 






« C-Plane routing » 


000 


Cf never 






« Slot size » 


0001 


long slot 
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D.1 .2.2 Outgoing Call Wideband, codec list, negotiation results in Wideband 

Use case: User requests a wideband call but specifies another NB codec in the SETUP (instead of 
ITU-T Recommendation G.726 [15]), but network only supports ITU-T Recommendation G.722 [17]. 



PP 



FP 



IP-Network 



WB call initiated 



mac setup -> longslot 



CC-SETUP 



«Basic Service=88» 

«Codec-List» 



CC-CALL-PROC 



CC-CONNECT 



«Codec-List = G.722» 



INVITE (SDP: G722, PCMA, PCMU, 



200 OK (SDP: G722) 



wideband 



ACK 



Figure D.2: Outgoing Call Wideband, codec list, negotiation results in Wideband 
Table D.3: Values used within the {CC-SETUP} message 



Information 
element 


Information 
Element Coding 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


« Basic Service » 


e0 88 












« Call class » 


1000 


Normal call setup 






« Basic Service » 


1000 


Wideband speech default setup 
attributes 


«Codec-List» 


7c 07 90 03 00 01 
02 00 84 












« Negotiation indicator» 










«1st codec identifier» 


0000011 


ITU-T Recommendation G.722 [17] 






« MAC service » 


0000 


In min delay 






« C-Plane routing » 


000 


Cf never 






« Slot size » 


0001 


long slot 






«2nd codec identifier» 


0000100 


ITU-T Recommendation G. 711 [16] 






« MAC service » 


0000 


In min delay 






« C-Plane routing » 


000 


Cf never 






« Slot size » 


0001 


long slot 






«3rd codec identifier» 


0000010 


G.726 






« MAC service » 


0000 


In min delay 






« C-Plane routing » 


000 


Cf never 






« Slot size » 


0100 


Full slot 



Here, a new codec -list is offered in the CC-SETUP. 

Again, in a response message (here CC-Connect), the peer entity confirms the chosen service with the IE 
«Codec-List». 

Table D.3 shows the IE codings for this example. 
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D.1 .2.3 Outgoing call with progress indicator with negotiation results in 
CC-INFO 



Use case: User requests a wideband call and Fixed Part uses Progress indicator messages. 



PP 



WB call initiated 



mac setup -> longsloT 



CC-SETUP 



«Basic Service=88» 
«Codec-List»* 



CC-CALL-PROC 



CC-INFO 



«Progress lndicator» 
«Codec-List = G.722» 



CC-CONNECT 



FP 



IP-Network 



INVITE (SDP: G722, PCMA, PCMU,...) 



183 RINGING (SDP: G722) 



wideband 



200 OK (SDP: G722) 



wideband 



ACK 



Figure D.3: Outgoing call with progress indicator with negotiation results in CC-INFO 

In case the IE «Progress Indicator» is used to connect the U-Plane before {CC-CONNECT}, the service shall be 
confirmed at latest in the same message. 

If the service negotiation via the network interface results in the need to change the codec in DECT again, this has to be 
done with the service change procedure (before or after CC-CONNECT). 
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D.1 .2.4 Outgoing call with progress indicator; with negotiation results in 
CC-INFO codec change in 200 OK 

Use case: User requests outgoing wideband call but the codec changes between RINGING and OK messages on the IP 
network. 



PP 



WB call initiated 



mac setup -> longslot 



CC-SETUP 



«Basic Service=88» 
«Codec-List»* 



CC-CALL-PROC 



CC-INFO 



FP 



«Progress lndicator» 
« Codec-List = G.711» 



CC-SERVICE-CHANGE 



« Codec-List =G.722» 



CC-SERVICE-ACCEPT 



IWII-INFQ 

« Codec-List =G.7 



IWU-INFO 



: Codec-List =G.722> 



CC-CONNECT 



INVITE (SDP: G722, PCMA, PCMU,. 



183 RINGING (SDP:G711) 



200 OK (SDP: G722) 



wideband 



ACK 



IP-Network 



Figure D.4: Outgoing call with progress indicator; 
with negotiation results in CC-INFO codec change in 200 OK 

In this case the codec is changed but the slot format remains unchanged. {IWU-INFO} is exchanged although before 
CONNECT. 
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D.1 .2.5 Outgoing Call Wideband, negotiation results in Narrowband 

Use case: user requests wideband outgoing call but the IP network does not support wide band 
PP FP 



IP-Network 



WB call initiated 



mac setup -> longslot 




CC-SETUP 



«Basic Service=88» 
«Codec-List»* 



CC-CALL-PROC 



CC-CONNECT 



« Codec-List = G.726» 



connection modification -> fullslot 




INVITE (SDP: G722, PCMA, PCMU,...) 



200 OK (SDP: PCMA) 



narrowband 



ACK 



Figure D.5: Outgoing Call Wideband, negotiation results in Narrowband 
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D.1 .2.6 Outgoing Call Wideband, negotiation results in longslot 

Use case: User requests outgoing wideband call but establishes the radio link in full-slot. 



PP 



WB call 



mac setup -> fullslot 



CC-SETUP 



«Basic Service=88» 
«Codec-List»* 

CC-CALL-PROC 



CC -CONNECT 



FP 



IP-Network 



«Codec-List = G.722» 



connection modification -> longslot 



INVITE (SDP: G722, PCMA, PCMU,...) 



200 OK (SDP: G722) 



wideband 



ACK 



Figure D.6: Outgoing Call Wideband, negotiation results in longslot 

It is also possible to establish a full slot connection during call establishment and modify it to a long slot connection 
after negotiation, if necessary. However it is not recommended, since it might be possible that modification from 
fullslot to longslot fails due to limited MAC resources (result would appear in the connection attributes of the 
CC-CONNECT message) 
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D.1 .3 Incoming Call Wideband 

D.1 .3.1 Incoming Call Wideband, negotiation results in Wideband 



Use case: Explicit in the figures title. 
PP 



FP 



IP-Network 



LCE-REQ-PAGE (long) 


_ INVITE (SDP: G722, PCMA, PCMU,...) 


wideband 

200 OK (SDP: G722) 




mac setup -> longslot 2I> 


CC-SETUP 


«Basic Service=88» 
«Codec-List» * 

CC-ALERT 


«Codec-List = G.722» 

CC-CONNECT 


CC-CONNECT-ACK 


wideband 

ACK 







Figure D.7: Incoming Call Wideband, negotiation results in Wideband 
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D.1 .3.2 Incoming Call Wideband, negotiation results in Narrowband 

Use case: User receives incoming call in wideband preferred but a narrow band connection is set up (for example if we 
pickup the call on a NB handset) 

PP 





LCE-REQ-PAGE (long) 


IN 


VI I L (bUK! bffi,rtMA, ^U\ 


/IU,...) 






wideband 

200 OK (SDP: PCMA) 








mac setup -> lonqslot H> 


CC-SETUP 




«Basic Service=88» «Codec-List» * 

CC-ALERT 




«Codec-List = G.726» 


connection modification -> fullslot 


CC-CONNECT 


CC-CONNECT-ACK 




narrowband 


AGK 

















Figure D.8: Incoming Call Wideband, negotiation results in Narrowband 
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D.1 .3.3 Incoming Call Wideband, No SDP Offer in Invite, negotiation results 
in Narrowband 

Use case: User receives an incoming call, FP proposes to establish in WB but network forces narrow-band. 

PP FP IP-Network 





LCE-REQ-PAGE (long) 






ACK (SDP: PCMU) 
200 OK (SDP: G722, PCMA, PCMU,...) 




mac setup -> lonqslot ^> 


^ CC-SETUP 




«Basic Service-88» «Codec-List» * 

CC-ALERT 


«Codec-List = G.722» 

CC-CONNECT „ 


4 CC-CONNECT-ACK 


wideband 

INVITE 






CC-SERVICE-CHANGE 


narrowband 






«Codec-List = G726» «Service Change lnfo» 

CC-SERVICE- „ 






ZL connection modification -> fullslot 


^^"^ IWU-INFO 




«Codec-List = G726» 

IWU-INFO 




«Codec-List = G726» * 



Figure D.9: Incoming Call Wideband, No SDP Offer in Invite, negotiation results in Narrowband 

In this case the FP has to assume a service in order to be able to propose one to the PP in the {CC-SETUP} message. 
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D.1 .4 Service Change 

D.1 .4.1 Service Change from Wideband to Narrowband; re-negotiation 
initiated from IP-Network 



Use case: network requests a codec change (for example call waiting). 



PP 
I 



FP 
I 



IP- Network 



Longslot, G.722 



CC-SERVICE-CHANGE 



«Codec-List = G.726» «Service Change lnfo» 

CC-SERVICE-ACCEPT 



connection modification -> fullslot 



IWU-INFO 



«Codec-List = G.726» 



IWU-INFO 



«Codec-List - G.726> 



INVITE (SDP: PCMA, PCMU,...) 



200 OK (SDP: PCMA) 



AGK 



Fullslot, G.726 



I I 

Figure D.10: Service Change from Wideband to Narrowband; re-negotiation initiated from IP-Network 

The peer side can either accept the proposal by answering CC-SERVICE-ACCEPT or reject it with 
CC-SERVICE-REJECT. In the latter case there will be no changes. In the first case the side indicated as master in the 
IE «Service change info» will initiate the agreed changes. 

Table D.3: Values used in the {CC-SERVICE-CHANGE} message 



Information 
element 


Information 
Element 
Coding 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


«Codec-List» 


7c 04 90 02 00 84 












« Negotiation 
indicator» 










«2 m codec identifier» 


0000010 


ITU-T Recommendation G.726 [15] 






« MAC service » 


0000 


In min delay 






« C-Plane routing » 


000 


Cf never 






« Slot size » 


0100 


Full slot 


« Service Change 
Info » 


16 01 9d 


< coding standard > 


00 


Dect 






< Master > 


1 


Receiving side (always PP) 






< Change mode > 


1101 


Audio codec change 
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Table D.4: Values used within both {IWU-INFO} messages 



Information 
element 


Information 
Element 
Coding 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


«Codec-List» 


7c 04 90 02 00 84 












« Negotiation 
indicator» 










«2" a codec identifier» 


0000010 


ITU-T Recommendation G.726 [15] 






« MAC service » 


0000 


In min delay 






« C-Plane routing » 


000 


Cf never 






« Slot size » 


0100 


Full slot 
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D.1 .4.2 Service Change from Wideband to Narrowband; re-negotiation 
initiated from FP 

Use case: FP requests codec change on IP network in order to change the radio format on the DECT link (release radio 
resources for example). 



PP FP 
i i 


INVITE (SDP: PCMA, PCMU,...) 


IP-Net 


Longslot, G.722 




CC-SERVICE-CHANGE 






200 OK (SDP: PCMA) 






ACK 




«Codec-List = G.726» «Service Change lnfo» 

CC-SERVICE-ACCEPT 




<^ connection modification -> fullslot 


IWU-INFO 


«Codec-List = G.726» 
IWU-INFO 


«Codec-List = G.726» 








Fullslot, G.726 









Figure D.11: Service Change from Wideband to Narrowband; re-negotiation initiated from FP 
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D.1 .4.3 Service Change from Wideband to Narrowband; PP initiated; IP 
Network accepts Narrowband Codec 

Use case (example): user connects a narrow-band headset on the PP during an established wideband call 



PP 



FP 



IP-Network 















Longslot, G.722 






CC-SERVICE-CHANGE 








«Codec List» «Service Change lnfo» 

CC-SERVICE-ACCEPT 




INVITE (SDP: PCMA. PCMU....) 




200 OK (SDP: PCMA) 






ACK 












connection modification -> fullslot 




IWU-INFO 




«Codec-List = G.726» 
IWU-INFO 




«Codec-List = G.726» 












Fullslot, G.726 

















Figure D.12: Service Change from Wideband to Narrowband; 
PP initiated; IP Network accepts Narrowband Codec 
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D.1 .4.4 Service Change from Wideband ITU-T Recommendation G.722 to 
Narrowband; PP initiated; IP Network does not accept Narrowband 
Codec 



pp 



FP 



IP-Network 











Longslot, G.722 






CC-SERVICE-CHANGE 








«Codec List» «Service Change lnfo» 

„ OO-RFRVIOF-RF.IFOT 


INVITE (SDP: PCMA, PCMU,...) „ 




REJECT 488 NOT ACCEPTABLE HERE 














Longslot, G.722 










ACK 









Figure D.13: Service Change from Wideband ITU-T Recommendation G.722 to Narrowband; 
PP initiated; IP Network does not accept Narrowband Codec 

Use case: User connects a NB headset during established call on the PP, but the codec is refused by the network. 
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D.1.5 Internal Call 

D.1 .5.1 Intercom Call, PP2 confirms Wideband 

Use case: user requests a wideband intercom call and is successful because the other PP supports wideband. 

PP 1 FP PP2 



WB call initiated 



mac setup -> longslot 



CC-SFTliP 



«Basic Service=98» 
«Codec List»* 



CC-CALL-PROC 



CC-CONNECT 



«Codec List = G.722» 



LCE-REQ-PAGE (long) 



mac setup -> longslot 



CC-SETUP 



«Basic Service=88» 
«Codec List»* 



CC-CONNECT 



«Codec List = G.722» 



CC-CONNECT-ACK 



Figure D.14: Intercom Call, PP2 confirms Wideband 
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D.1 .5.2 Intercom Call, PP2 confirms narrowband 

Use case: user requests a wideband intercom call but other PP refuses wideband (narrowband headset connected to a 
wideband PP for example). Intercom call established in narrowband. 



PP 1 



FP 



PP2 



WB call initiated 



mac setup -> longslot 



CC-SETUP 



<Basic Service=98» 
<Codec List» * 



CC-CALL-PROC 



CC-CONNECT 



« Codec List = G.726» 



connection modification -> fullslot 



LCE-REQ-PAGE (long) 



mac setup -> longslot 



CC-SETUP 



«Basic Service=8 
«Codec List» * 



CC-CONNECT 



« Codec List = G.726» 

CC-CONNECT-ACK 



connection modification -> fullslot 



Figure D.15: Intercom Call, PP2 confirms narrowband 
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D.1 .5.3 Intercom Call with Interworking: WB Handset -> NB Handset 

Use case: User requests an intercom call between New Generation DECT PP1 to a standard DECT PP2 on the same FP. 



PP1 



WB call initiated 



mac setup -> longslot 



CC-SETUP 



«Basic Service=98> 
« Codec List » * 



CC-CALL-PROC 



CC-CONNECT 



« Codec List = G.726» 



connection modification -> fullslot 



FP 



LCE-REQ-PAGE (full) 



mac setup -> fullslot 



CC-SETUP 



«Basic Service=80» 



CC-CONNECT 



CC-CONNECT-ACK 



PP2 



Figure D.16: Intercom Call with Interworking: WB Handset -> NB Handset 

Other use case: User requests an intercom call between New Generation DECT PP1 to a standard DECT PP2 on the 
same FP, but FP requests to change radio format earlier than CONNECT message. 



PP 1 



FP 



WB call initiated 



mac setup -> longslot 



CC-SETUP 



«Basic Service=98> 
« Codec List »* 



CC-CALL-PROC 



« Codec List = G722» 

CC-SERVICE-CHANGE 



« Codec List = G726» «Service Change Info 

CC-SERVICE-ACCEPT , 



con nection modification -> fullslot 



CC-CONNECT 



LCE-REQ-PAGE (full) 



mac setup -> fullslot 



CC-SETUP 



«Basic Service=80» 



CC-CONNECT 



CC-CONNECT-ACK 



PP2 



Figure D.17: Intercom Call with Interworking: WB Handset -> NB Handset, alternative procedure 
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D.1 .5.4 Internal Call transfer, WB -> NB 



Use case: New Generation DECT PP1 in communication, PP1 initiates an internal call with New Generation DECT 
PP2, PP2 switches to narrowband due to narrowband headset use. 



PP2 



PP1 



Call in PP1 with longslot, G.722 



LCE-REQ-PAGE (long) 



mac setup -> longslot 



CC-CONNECT 



<Codec List = G.726» 



CC-SETUP 



«Basic Service=88» 
«Codec List» * 



connection modification -> fullslot 



CC-CONNECT-ACK 



FP 



IP-Network 



INVITE (SDP: PCMA, 
PCMU,...) 



200 OK (SDP: PCMA) 



ACK 



Call in PP2 with fullslot, G.726 



Figure D.18: Internal Call transfer between two NG PPs, initiated as WB and switched later to NB 

Other use case: New Generation DECT PP1 in communication, PP1 initiates an internal call with standard DECT PP2, 
call established in narrowband. 



PP2 



PP1 



FP 



IP-Network 







( Call in PP1 with longslot, G.722 


ZJ 






LCE-REQ-PAGE 


INVITE (SDP: PCMA, 
PCMU,...) ^ 










mac setup -> fullslot ZH^==- 






CC-SETUP 






CC-CONNECT 


«Basic Service=80» 






CC-CONNECT-ACK 




200 OK (SDP: PCMA) 




ACK 










( 


Call in PP2 with fullslot, G.726 


J 



Figure D.19: Internal Call transfer from a NG PP to a PP which does not support wideband 
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D.1 .5.5 Internal Call transfer, NB -> WB 

Use case: New Generation DECT PP1 transfers a call to a New Generation DECT PP2. 



PP2 



PP1 



Call in PP1 with fullslot, G.726 



LCE-REQ-PAGE 



mac setup -> longslot 



CC-CONNECT 



« Codec List = G.722» 



CC-SETUP 



«Basic Service=88» 
«Codec List» * 



Call in PP2 with longslot, G722 



FP 



IP-Network 



INVITE (SDP: G722, 



200 OK (SDP: G722) 



Figure D.20: Internal Call transfer, NB -> WB 
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D.1 .5.6 Internal Call transfer, NB -> WB, IP negotiation results in NB 

Use case: New Generation DECT PP1 transfers a narrowband external call to New Generation DECT PP2, requests on 
IP for wideband is refused by the network. External call is transferred in the same codec: narrowband. 



PP2 



PP1 



FP 



IP-Network 



mac setup -> longslot 



CC-CONNECT 



« Codec List = G.722> 



CC-SERVICE-ACCEPT 



Call in PP1 with fullslot, G.726 



LCE-REQ-PAGE 



CC-SETUP 



«Basic Service=88» 
« Codec List » 



CC-SERVICE-CHANGE 



« Codec List = G726 » «Service 



connection modification -> fullslot 



IWU-INFO 



«Codec-List = 



IWU-INFO 



«Codec-List = 
G.726» 



INVITE (SDP:G722, 
PCMA...) 



„ 200 OK (SDP: PCMA) 



ACK 



Call in PP2 with fullslot, G.726 



] 



Figure D.21 : Internal Call transfer, NB -> WB, IP negotiation results in NB 
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D.1.6 Special cases 

D.1 .6.1 Service Change from Wideband to Narrowband with Call Waiting 

Use case: User accepts a call waiting from IP-Network. 



PP FP 

i i 


INVITE (SDP: PCMA, PCMU,...) 


IP-Nel 


Longslot, G.722 










> 


200 OK (SDP: PCMA) 




< 


Accept Call waiting 




„ CC-SERVICE-CHANGE 




«Codec List = G726» «Service Change info» 
CC-SERVICE-ACCEPT 










ACK 






<CI connection modification -> fullslot 




^ IWU-INFO 












""" «Codec-List = G.726» 

IWU-INFO 




«Codec-List = G.726» 


Fullslot, G.726 



Figure D.22: Service Change from Wideband to Narrowband with Call Waiting 
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D.1 .6.2 Service Change from Wideband to Narrowband with Call Hold 

Use case: User requests a call hold during a wideband call and requests a new call setup in narrowband accepted by the 
IP network. 



PP 



FP 



IP-Network 



Longslot, G.722 












< 


Call hold and initiate a new call 


> 

INVITE (SDP: PCMA, PCMU,...) 




CC-SERVICE-CHANGE 




200 OK (SDP: PCMA) 




ACK 




«Codec List = G726» «Service Change lnfo» 

CC-SERVICE-ACCEPT 








<d connection modification -> fullslot 




^ IWU-INFO 




«Codec-List = G.726» 

IWU-INFO „ 




«Codec-List = G.726» 






Fullslot, G.726 

1 — i - 1 ' 





Figure D.23: Service Change from Wideband to Narrowband with Call Hold 
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D.1 .6.3 Service Change from Wideband to Narrowband; Network layer 
Acknowledgment 



Use case: Change codec or audio format during a communication without audio artefacts. 



PP 

I 



Longslot, G.722 



CC-SERVICE-CHANGE 



«Codec List = G726» «Service Change lnfo» 

CC-SERVICE-ACCEPT 



c onnection modification -> fullslot 



7 



IWU-INFO 



«Codec-List = G.726» 



IWU-INFO 



«Codec-List - G.726» 



FP 

I 



IP-Network 



INVITE (SDP: PCMA, PCMU,...) 



200 OK (SDP: PCMA) 




V 



Send audio in new format 



Figure D.24: Service Change from Wideband to Narrowband; Network layer Acknowledgment 

The IWU-INFO is sent by both sides. The service change from Narrowband to Wideband is performed in the same way. 
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D.1 .6.4 Service Change from Narrowband to Wideband fails; Network layer 
Acknowledgment 

Use case: Failure in change of codec or audio format during a communication without audio artefacts. 



PP 
_L_ 



FP 



Fullslot, G.726 



CC-SERVICE-CHANGE 



<Codec List = G722» «Service Change lnfo> 



OC-RFRVIOF-ACCFPT 



connection modification fails 



7 



v7 

IWU-INFO \g/ 



«Codec-List = G.726» 



IWU-INFO 



<Codec-List = G.726» 



IP-Network 



Figure D.25: Service Change from Narrowband to Wideband fails; Network layer Acknowledgment 

The IWU-INFO is sent by both sides. The service change from Narrowband to Wideband is performed in the same way. 
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D.1 .6.5 Outgoing Call, slot type modification fails 

Use case: Slot type modification after negotiation fails. 

PP FP 



WB call initiated 



mac setup -> full slot 



CC-SETUP 



«Basic Service=88» 
«Codec-List»* 



CC-CALL-PROC 



CC-CONNECT 



: Codec-List - G.722» 



connection modification fails 



IWU-INFO 



«Codec-List = G.726» 



IP-Network 



IWU-INFO 



«Codec-List = G.726» 



Figure D.26: Outgoing Call, slot type modification fails 
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D.2 Examples of implementation of procedures for 
MPEG-4 ER AAC-LD voice service 

D.2.1 MPEG-4 ER AAC-LD voice service codec configuration and 
negotiation process 

In annex C, the signalling of the MPEG-4 ER AAC-LD configuration using two «IWU to IWU» elements is defined. 
The following informative flowcharts describe the handling of the codec configuration and negotiation process in case 
of a MPEG-4 ER AAC-LD voice service selection. Furthermore the Session Initiation Protocol [27] for call 
establishment of the Voice over IP call is assumed. 

D.2.1 .1 Transmitting non default configuration using 

«LOCATE-REQUEST», «LOCATE-ACCEPT» Message 

Use case: Explicit in the figures title. 

PP FP 



LOCATE-REQUEST 



«Codec-List» 

«IWU to IWU» (MPEG4CapabilityElement) 

Describing the supported capabilities from PP Side 



LOCATE-ACCEPT 



«Codec-List» 

«IWU to IWU» (MPEG4CapabilityElement) 

Describing the supported capabilities from FP Side 



Figure D.27: Transmitting non default configuration using 
«LOCATE-REQUEST», «LOCATE-ACCEPT» Message 
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D.2.1 .2 Transmitting non default configuration using 
«ACCESS-RIGHTS-REQUEST», 
« ACCESS-RIGHTS-ACCEPT» Message 



Use case: Explicit in the figures title. 

PP 



ACCESS-RIGHTS-REQUEST 



«Codec-List» 

«IWU to IWU» (MPEG4CapabilityElement) 

Describing the supported capabilities from PP Side 

ACCESS-RIGHTS-ACCEPT 



«Codec-List» 

«IWU to IWU» (MPEG4CapabilityElement) 

Describing the supported capabilities from FP Side 



FP 



Figure D.28: Transmitting non default configuration using 

«ACCESS-RIGHTS-REQUEST», 

« ACCESS-RIGHTS-ACCEPT» Message 
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D.2.1 .3 Outgoing Call Super Wideband, codec MPEG-4 ER AAC-LD 



Use case: Explicit in the figures title. 



PP 



FP 



IP-Network 



_L 



WB call initiated 



mac setup -> 



CC-SETUP 



«Basic Service=88» 

«Codec-List» 

«IWU to IWU» (MPEG4ConfiguartionElement) including ASC of 

PP 

CC-CALL-PROC 



CC-CONNECT 



«Codec-List = MPEG-4 ER AAC-LD» 
«IWU to IWU»(MPEG4ConfiguartionElement) 
including ASC of FPortheASCof IP Network 



INVITE (SDP: G722, MPEG4- 
GENERIC/ MP4A-LATM) 



200 OK (SDP: MPEG4-GENERIC/ 
MP4A-LATM) 



super wideband 



ACK 



D.2.1. 3.1 



Figure D.29: Outgoing Call Super Wideband, codec MPEG-4 ER AAC-LD 

Outgoing Call Super Wideband, INVITE command: AudioSpecificConfigQ 



In the MPEG4-GENERIC/MP4A-LATM part of the SDP content (during the INVITE command) the 
AudioSpecificConfigO (ASC) of the PP or the FP has to be transmitted to signal the used MPEG-4 ER AAC-LD 
configuration. The SDP content during the INVITE command can be described as follow. 

G722 codec part: 

m=audio 49230 RTP/AVP 9 

a=rtpmap:9 G722/8000 
The description for MPEG-4 ER AAC-LD can be transmitted using two different RFCs (3016 and 3640): 
RFC 3640 [22]: 

m=audio 49230 RTP/AVP 96 

a=rtpmap : 96 mpeg4 -generic/ 4 8000/1 

a=fmtp:96 streamtype=5 ; prof ile-level-id=52 ; mode=AAC-hbr ; 

config=ASC; sizeLength=13 ; indexLength=3 ; indexDeltaLength=3 ; 
constantDuration=480; 

RFC 3016 [23]: 

m=audio 49230 RTP/AVP 96 

a=rtpmap: 96 MP4A-LATM/4 8000 

a=fmtp:96 prof ile-level-id=52 ; bitrate=64000 ; cpresent=0; 

conf ig=ASC; 
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D.2.1 .3.2 Outgoing Call Super Wideband, OK command: AudioSpecificConfig() 

In the MPEG4-GENERIC/MP4A-LATM part of the SDP content (during the OK command) the AudioSpecificConfigO 
(ASC) of the IP remote station has to be transmitted to signal the used MPEG-4 ER AAC-LD configuration. The SDP 
content during the OK command can be described as follow. 

RFC 3640 [22]: 

m=audio 49230 RTP/AVP 96 

a=rtpmap : 96 mpeg4 -generic/ 4 8000/1 

a=fmtp:96 streamtype=5 ; prof ile-level-id=52 ; mode=AAC-hbr ; 

config=ASC; sizeLength=13 ; indexLength=3 ; indexDeltaLength=3 ; 
constantDuration=480; 

RFC 3016 [23]: 

m=audio 49230 RTP/AVP 96 

a=rtpmap:96 MP4A-LATM/4 8000 

a=fmtp:96 prof ile-level-id=52 ; bitrate=64000 ; cpresent=0; 

conf ig=ASC; 
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D.2.1 .4 Incoming Call Super Wideband, codec MPEG-4 ER AAC-LD 



Use case: Explicit in the figures title. 
PP 



FP 



IP-Network 



LCE-REQUEST-PAGE (longslot) 


INVITE (SDP: G722, MPEG4- 
GENERIC/ MP4A-LATM) 




wideband 

200 OK (SDP: MPEG4-GENERIC/ 
MP4A-LATM) 




mac setup -> longslot 2I> 


% CC-SETUP 


«Basic Service=88» 

«Codec-List» * 

«IWU TO IWU» (MPEG4ConfiguartionElement) 

including ASC 

CC-ALERT 


«Codec-List = MPEG-4 ER AAC-I_D» 

«IWU TO IWU» (MPEG4ConfiguartionElement) including 

CC-CONNECT 


CC-CONNECT-ACK 


superwideband 
ACK 











Figure D.30: Incoming Call Super Wideband, codec MPEG-4 ER AAC-LD 

D.2.1 .4.1 Incoming Call Super Wideband, INVITE command: AudioSpecificConfig() 

In the MPEG4-GENERIC/MP4A-LATM part of the SDP content (during the INVITE command), the 
AudioSpecif icConf ig ( ) (ASC) of the IP remote station or the FP has to be transmitted to signal the used MPEG- 
4 ER AAC-LD configuration. The SDP content during the INVITE command can be described as follow. 

ITU-T Recommendation G.722 [17] codec part: 

m=audio 49230 RTP/AVP 9 

a=rtpmap:9 G722/8000 
The description for MPEG-4 ER AAC-LD can be transmitted using two different RFCs (3016 and 3640): 
RFC 3640[22]: 

m=audio 49230 RTP/AVP 96 

a=rtpmap : 96 mpeg4 -generic/ 4 8000/1 

a=fmtp:96 streamtype=5 ; prof ile-level-id=52 ; mode=AAC-hbr ; 

config=ASC; sizeLength=13; indexLength=3 ; indexDeltaLength=3 ; 
constantDuration=480; 

RFC 3016 [23]: 

m=audio 49230 RTP/AVP 96 

a=rtpmap:96 MP4A-LATM/4 8000 

a=fmtp:96 prof ile-level-id=52 ; bitrate=64000 ; cpresent=0; 

conf ig=ASC; 
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D.2.1 .4.2 Incoming Call Super Wideband, OK command: AudioSpecificConfig() 

In the MPEG4-GENERIC/MP4A-LATM part of the SDP content (during the OK command) the 
AudioSpecificConfigO (ASC) of the PP has to be transmitted to signal the used MPEG-4 ER AAC-LD 
configuration. The SDP content during the OK command can be described as follows: 

RFC 3640 [22]: 

m=audio 49230 RTP/AVP 96 

a=rtpmap : 96 mpeg4 -generic/ 4 8000/1 

a=fmtp:96 streamtype=5 ; prof ile-level-id=52 ; mode=AAC-hbr ; 

config=ASC; sizeLength=13 ; indexLength=3 ; indexDeltaLength=3 ; 
constantDuration=480; 

RFC 3016 [23]: 

m=audio 49230 RTP/AVP 96 

a=rtpmap:96 MP4A-LATM/4 8000 

a=fmtp:96 prof ile-level-id=52 ; bitrate=64000 ; cpresent=0; 

conf ig=ASC; 
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Annex E (normative): 
Frame formats 

E.1 Transport of the ITU-T Recommendation G. 729.1 
audio frame in full-slot mode 

This clause specifies the format of the ITU-T Recommendation G.729.1 [18] audio frame in the B field. This format 
shall be used in both directions (from PT to FT and from FT to PT). 

The same format may be re-used for any frame oriented codec using a bit rate up to 30,4 kbit/s. 



Full slot 1 - B field (320 bits) 



Code Word Audio codec payload parti Pad. 



Code word 
16 bits 



FPA BFI 



Audio codec 
payload 
<304 bits 



Optional 
padding 
n bits 



Full slot 2 - B field (320 bits) 




v * 


Code Word 


Audio codec payload part2 


Pad. 



Code word Audio codec payload Optional 
16 bits <304bits padding 

nbits 



FPA BFI 



Figure E.1 : Transport of framed audio codec payload in full slot mode 

The code word is generic for any framed codec. The audio codec payload format is codec dependent. 

Audio codec payload part 1 and 2 are simply concatenated to obtain the complete audio payload format described in 2) 
below. 

1) The code word is coded as follows: 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 


Octet 




PA 


X 


X 


X 


X 


FPA2 


FPA1 


BFI 


1 




X 


X 


X 


X 


X 


X 


X 


X 


2 



Figure E.2: Code word coding 

Bad frame indicator (bit 1): 

This bit indicates whether the current audio frame is valid or not. It may be set to 1 if an IP packet loss is detected in the 
FP, or if any other transmission problem has occurred which damages the integrity of the frame. It is not recommended 
to use it in the PP to FP direction. 



Bit 



1 


1 



Meaning 

The audio frame is valid 

The audio frame is not valid (packet loss detected in the network above the FP) 



Frame Part (FPA1, FPA2): 



Bits 3 2 

00 
01 
10 

1 1 



Meaning 

First audio frame part 

Second audio frame part 

Third audio frame part (not used for ITU-T Recommendation G.729.1) 

Fourth audio frame part (not used for ITU-T Recommendation G.729.1) 
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Parity bit (PA): 
Bit 8 

x Even parity. Total number of " 1 " (including this bit) must be even in the first octet. 

Other bits (octet 1 bits 4 to 8, octet 2 bits 1 to 8): 

For future use. For example, additional protection of payload bits (redundancy, CRC etc.). 

2) The audio payload format coding is codec-dependent: 

Case 1: ITU-T Recommendation G.729.1 [18] payload format 

The same coding is used as in RFC 4749 [24]. 

ITU-T Recommendation G.729.1 [18] is used at the maximum bit rate of 30 kbit/s in order to fit into the B field size 
(<30,4 kbit/s). The audio codec frame is defined as in RFC: 

G.729.1 payload format : 608 bits max (case 30 kbits/s) 



MBS FT Audio encoded data 



4 4 

Payload Header 

8 bits 



Coding of the Payload header: 



Audio codec frame 
Up to 600 bits (case 30 kbit/s) 

Figure E.3: G.729.1 payload format 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 




MBS4 


MBS3 


MBS2 


MBS1 


FT4 


FT3 


FT2 


FT1 



Figure E.4: Payload header coding 

FT field (4 bits): 

Frame type of the audio encoded data. The value of the FT field is set according to the following table: 
FT4 to FT1: 



0000 





8 


kbit/s 


20 


octets | 


0001 


1 


12 


kbit/s 


30 


octets | 


0010 


2 


14 


kbit/s 


35 


octets | 


0011 


3 


16 


kbit/s 


40 


octets | 


0010 


4 


18 


kbit/s 


45 


octets | 


0101 


5 


20 


kbit/s 


50 


octets | 


0110 


6 


22 


kbit/s 


55 


octets | 


0111 


7 


24 


kbit/s 


60 


octets | 


0100 


8 


26 


kbit/s 


65 


octets | 


1001 


9 


28 


kbit/s 


70 


octets | 


1010 


10 


30 


kbit/s 


75 


octets | 


1011 


11 


32 


kbit/s 


80 


octets | 


1100 


12 


(reserved) 






1101 


13 


(reserved) 






1110 


14 


(reserved) 






1111 


15 


NO_ 


_DATA 




1 



(recommended default value for G.729.1) 
(value not possible for G.729.1 on DECT 
link in full-slot mode) 



The FT value 15 (NO_DATA) indicates that there is no audio data in the payload. This MAY be used to update the 
MBS value when there is no audio frame to transmit. The payload will then be reduced to the payload header. 
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If a payload with a reserved FT value is received, the whole payload MUST be ignored. 

MBS field (4 bits) = Maximum bit rate supported. 

It indicates a maximum bit rate to the encoder at the site of the receiver of this payload. The MBS is used to tell the 
other party the maximum bit rate one can receive. The encoder MUST NOT exceed the sending rate indicated by the 
received MBS. 

NOTE: Due to the embedded property of the coding scheme, the encoder can send frames at the MBS rate or any 
lower rate. As long as it does not exceed the MBS, the encoder can change its bit rate at any time without 
previous notice. 

The value of the MBS field is set according to the following table: 



MBS 4 to MBS1 






0000 





8 kbit/s | 


0001 


1 


12 


kbit/s | 


0010 


2 


14 


kbit/s | 


0011 


3 


16 


kbit/s | 


0100 


4 


18 


kbit/s | 


0101 


5 


20 


kbit/s | 


0110 


6 


22 


kbit/s | 


0111 


7 


24 


kbit/s | 


1000 


8 


26 


kbit/s | 


1001 


9 


28 


kbit/s | 


1010 


10 


30 


kbit/s | 


1011 


11 


32 


kbit/s | 


1100 


12 


(reserved) | 


1101 


13 


(reserved) | 


1110 


14 


(reserved) | 


1111 


15 


NO_ 


_MBS | 



(recommended default value for G. 729.1) 

(value not possible for G. 729.1 on DECT link in 

full-slot mode) 



So the default normative recommended value for MBS is 10 and for FT is 10, for direction PP to FP. For the direction 
FP to PP of course MBS and FT are dependent of what is really received from the distant but MUST NOT be set to 1 1 
which is a non authorized value on DECT link. 

For FT (Frame Type) below 10 (bit rate below 30 kbit/s) padding are used as necessary on B field part. 

Example 1: with a FT of 7 (24 kbit/s) that corresponds to ITU-T Recommendation G. 729.1 [18] payload format frame 
of 8 (header) + 480 (audio frame) = 488 bits. Full slot 1 is then composed of a code word of value 0x0100 followed by 
the first 304 bits of ITU-T Recommendation G.729. 1 [18] payload format and Full slot 2 is composed of a code word of 
value 0x0300 followed by last 184 bits ITU-T Recommendation G.729.1 [18] payload format, followed by 120 bits at 
zero (the padding bits). 

Example 2: with a FT of 1 (12 kbit/s) so corresponding to a complete ITU-T Recommendation G.729.1 [18] payload 
format frame of 8 (header) + 240 (audio frame) = 248 bits. Full slot 1 is then composed of a code word of value 0x0100 
followed by the full 248 bits of ITU-T Recommendation G.729.1 [18] payload format, followed by 56 bits at zero 
(padding bits) and Full slot 2 is composed of a code word of value 0x0300 followed by 304 bits at zero (only padding 

bits). 

In case of BFI frame (indicated with bfi = 1 in "code Word" part), the ITU-T Recommendation G.729.1 [18] payload 
format should be adapted with a FT of 15 (NO_DATA), a MBS of 15 (NO MBS) and a complete frame of (only 
padding). 

Case 2: other codec payload format 

To be defined for other codecs. 
3) Optional padding: 

to n bits. Not used for ITU-T Recommendation G.729.1 [18] at 30 kbit/s. 
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Annex F (normative): 

Amendments to other DECT specifications 

F.1 Amendments to EN 300 444 
(Generic Access Profile (GAP)) 

The following amendments to EN 300 444 [13] shall apply for the purpose of the present document. 

F.1 .1 Calling Line Identification Presentation (CLIP) 

F.1 .1.1 CLIP procedure description (add to clause 8 of EN 300 444) 

A new clause with the following text shall be added to clause 8 of EN 300 444 [13]: 

8.x Calling Line Identification Presentation (CLIP) Indication 

The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

Calling Line Presentation Indication may be sent either by including the «CALLING-PARTY-NUMBER» 
information element in the {CC-SETUP} message or in a {CC-INFO} message. The FT is required to support one of 
the methods, the PT is required to support both methods. 

For CLIP indication through the {CC-SETUP} see table 21, Values used within the {CC-SETUP} message. 

For CLIP indication through {CC-INFO} consider the following. 

Table x: Values used within the {CC-INFO} message 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
number» 








<Numbertype> 


All 




<Numbering plan id> 


All 




Presentation indicator 


All 




<Screening indicator 


All 




<Calling party address> 


All 





NOTE 1 : To support the feature in the PP, it is sufficient that the PP is capable to display the IA5 characters given 
in the field <Calling party address> according to its display capabilities without consideration of the 
contents of octets 3 and 3a. 

NOTE 2: In case both CLIP and CNIP are sent to the PP, it is sufficient to display CNIP. It is optional to display 
both. 

F.1. 2 Calling Name Identification Presentation (CNIP) 
F.1 .2.1 CNIP definition (add to clause 4.1 of EN 300 444) 

The following definition shall be added to clause 4.1 "Network (NWK) features" of EN 300 444 [13]: 

Calling Name Identification Presentation (CNIP) [N.34]: ability to provide the calling party name to the called party 
before accepting the call 
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F.1 .2.2 CNIP NWK feature (add to clause 6.2 of EN 300 444) 

The following entry shall be added to table 1 in clause 6.2 of EN 300 444 [13]: 

Table 1 : NWK features status 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 










R/B 


P 


N.34 


Calling Name Identification Presentation (CNIP) 


4.1 


O 


O 






F.1 .2.3 CNIP NWK feature to procedure mapping (add to clause 6.7 of EN 
300 444) 

The following entry shall be added to table 5 in clause 6.7 of EN 300 444 [13]: 

Table 5: NWK feature to procedure mapping 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 










R/B 


P 


N.34 Calling Name Identification 
Presentation (CNIP) 




4.1 


O 


O 


O 


Calling Name Identification Presentation 
(CNIP) Indication 


8.x 


M 


M 


M 



F.1 .2.4 CNIP procedure description (add to clause 8 of EN 300 444) 

A new clause with the following text shall be added to clause 8 of EN 300 444 [13]: 

8.x Calling Name Identification Presentation (CNIP) Indication 

The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

Calling Name Presentation Indication may be sent either by including the «CALLING-PARTY-NAME» information 
element in the {CC-SETUP} message or in a {CC-INFO} message. FT is required to support at least one of the 
methods, PT is required to support both. 

For CNIP indication through the {CC-SETUP} see table 21, with the following additions: 

Table x: Values added within the {CC-SETUP} message 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
name» 








Presentation indicator 


All 




<Screening indicator 


All 




<Calling party name> 


All 
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For CNIP indication through {CC-INFO} consider the following: 

Table x: Values used within the {CC-INFO} message 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
name» 








Presentation indicator 


All 




<Screening indicator 


All 




<Calling party name> 


All 





NOTE 1 : To support the feature in the PP, it is sufficient that the PP is capable to display the IA5 characters given 
in the field <Calling party name> according to its display capabilities without consideration of the 
contents of octet 3. 

NOTE 2: In case both CLIP and CNIP are sent to the PP, it is sufficient to display CNIP. It is optional to display 
both. 

F.1 .3 Internal Call CLIP and CNIP 

F.1 .3.1 Internal Call NWK feature to procedure mapping (modify clause 6.7 
of EN 300 444) 

The entry N.31 "Internal Call" in table 5, clause 6.7 of EN 300 444 [13] shall be modified as follows: 

Table 5: NWK feature to procedure mapping 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 










R/B 


P 


N.31 Internal Call 




4.1 


O 


O 





Internal call setup 


8.18 


M 


M 


M 


Internal call keypad 


8.19 


M 


O 


O 


Internal call CLIP 


8.x 
(F.1.3.2) 


O 


O 





Internal call CNIP 


8.x 
(F.1.3.3) 


O 


O 






F.1 .3.2 Internal Call CLIP procedure description 
(add to clause 8 of EN 300 444) 

A new clause with the following text shall be added to clause 8 of EN 300 444 [13]: 

8.x Internal Call Calling Line Identification Presentation (CLIP) 

The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

Calling Line Identification Presentation (CLIP), shall be implemented for internal calls. 

The general procedure for CLIP is described in clause 8.xx (F.l.l) "Calling Line Identification Presentation (CLIP) 
Indication" and it shall be used also for internal calls. 

NOTE 1 : The internal call CLIP indication can be used to convey internal handset number or any other number. 
External calling number could be used in case of call transfer. 
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NOTE 2: If internal call CLIP indication is used to indicate the handset number the following values for 
information element «Calling Party Number» should be used: 

Table x: Suggested values for «Calling Party Number» IE for internal calls 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
number» 








<Numbertype> 


3 


Network specific number 


<Numbering plan id> 


9 


Private plan 


Presentation 
indicator 


All 


Presentation allowed 


<Screening indicator 


All 


User-provided, verified and 
passed 


<Calling party 
address> 


IA5 coding of Terminal Identity 
Number in decimal 
representation 


Terminal Identity Number of the 
calling part 

- for FP 

- 1 to n for PP 



NOTE 3: See clause 14.4 for a description of the Terminal Identity Number and its use. 

NOTE 4: To support the feature in the PP, it is sufficient that the PP is capable to display the IA5 characters given 
in the field <Calling party address> according to its display capabilities without consideration of the 
contents of octets 3 and 3a. 

NOTE 5: In case both CLIP and CNIP are sent to the PP, it is sufficient to display CNIP. It is optional to display 
both. 

F.1 .3.3 Internal Call CNIP procedure description (add to clause 8 of 
EN 300 444) 

A new clause with the following text shall be added to clause 8 of EN 300 444 [13]: 

8.x Internal Call Calling Name Identification Presentation (CNIP) 

The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

Calling Name Identification Presentation (CNIP), shall be implemented for internal calls. 

The general procedure for CNIP is described in clause 8.x "Calling Name Identification Presentation (CNIP) Indication" 
(F. 1.2.4) and it shall be used also for internal calls. 

NOTE 1 : The internal call CNIP indication can be used to convey a user-friendly identifier associated with the PT. 
For example, in a residential environment, this identifier could be an alias for a room ("kitchen", "living 
room"), a person, etc. that the PT has a strong relationship with. 

NOTE 2: To support the feature in the PP, it is sufficient that the PP is capable to display the IA5 characters given 
in the field <Calling party name> according to its display capabilities without consideration of the 
contents of octet 3. 

NOTE 3: In case both CLIP and CNIP are sent to the PP, it is sufficient to display CNIP. It is optional to display 
both. 
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F.1 .4 Procedure to assign a simple identity number to each DECT 
entity in mono cell systems 

F.1 .4.1 Terminal identity number assignment in mono cell system definition 
(add to clause 4.2 of EN 300 444) 

The following definition shall be added to clause 4.2 "Application features" of EN 300 444 [13]: 

Terminal identity number assignment in mono cell system [A.4]: ability to assign to each PT a terminal identity 
number. 

F.1 .4.2 Terminal identity number assignment in mono cell system 
application feature (add to clause 6.6 of EN 300 444) 

The following entry shall be added to table 4 in clause 6.6 of EN 300 444 [13]: 

Table 4: Application features status 



Feature supported 




Status 


Item no. 


Name of feature 


Reference 


PT 


FT 










R/B 


P 


A.4 


Terminal identity number assignment in mono cell system 


4.2 


O 


O 


N/A 



F.1 .4.3 Terminal identity number assignment in mono cell system feature to 
procedure mapping 
(add to clause 6.8.3 of EN 300 444) 

The following entry shall be added to table 8 in clause 6.8.3 of EN 300 444 [13]: 

Table 8: Application feature to procedure mapping 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 










R/B 


P 


A.4 Terminal identity number 
assignment in mono cell system 




4.2 


O 


O 


N/A 


Terminal identity number assignment 


14.x, 
(F.1.4.2) 


O 


O 


N/A 



F.1 .4.4 Terminal identity number assignment in mono cell system procedure 
description (add to clause 14 of EN 300 444) 

A new clause with the following text shall be added to clause 14 of EN 300 444 [13]: 
14.x Terminal Identity number assignment in mono cell system 

14.X.1 General 

In a mono cell system for residential and small office applications, the terminal identity number is the number that can 
be: 

• used by the FT to identify the subscription data related to each PT (i.e. 1 to the maximum number of PT 
subscribed). The subscription data includes IPUI, PARK, terminal capabilities, etc.; 
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• displayed by each PP in Idle Locked mode (for example, "DECT 4" if the PP is the 4 th PT on the FT); 

• used to select the called DECT entity (PP or FP) when initiating Internal Call (for example, "Internal call to PP 
number 4"); 

• used to display the calling handset when receiving Internal Call (for example, "Internal call from PP 
number 4"); 

• used to select the suppressed PT when removing subscription data related on the FT. 

14.X.2 Procedure description 

At the FP side 

The terminal identity number value for the FT shall be 0. The identity number value for a PT should correspond to its 
subscription records number and should be in the limit (1, maximum number of subscription data on FT). 

The terminal identity number shall be assigned by the FT to each PT during the location registration procedure 

(see clause 8.28), and shall be of 8 bits length. The terminal identity number shall be the least significant bits part of the 

individual assigned TPUI. The most significant bits shall follow the rules of EN 300 175-6 [6], clause 6.31. 

The location registration procedure shall be used, (see clause 8.28) with the following replacement to the 
{LOCATE- ACCEPT} message. 

Table x: Values used within the {LOCATE-ACCEPT} message 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Portable- 
identity» 








<Type> 


32 


TPUI 


<Length of id value> 


20 




<Assignment type> 


1 


TPUI with number assigned 


<ldentity-value> 


Values in EN 300 175-6 [6] 
clause 6.3.1 are allowed 


Only assigned individual TPUIs are 
allowed 



At the PP side 

The Identity Number in the PT shall be derived from the individual assigned TPUI received during the location 
registration procedure (see clause 8.28). 

14.X.3 Related Procedures 

Internal call "called party" 

To select the called DECT entity, the dialled digit including in the «MULTI-KEYPAD» information element in the 
{CC-SETUP} message or in a {CC-INFO} message can be used with the following replacement: 

Table xx: Values used within the {CC-INFO} or {CC-SETUP} message for Internal Call 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Multi keypad» 


<Keypad information> 


IA5 coding of terminal identity 
number in decimal. (NOTE2) 


Terminal Identity Number of the 
called part 

- for FP 
1 to n if PP 


2AH 


Collective ringing (note 1) 



NOTE 1 : This value is used by the PP to request the FP to ring all the PP. 
NOTE 2: Example for coding of the Terminal Identity Number in IA5: 

• For terminal 1, terminal identity number is 0000 0001B, coded value is 31H. 

• For terminal 14, terminal identity number is 0000 1 HOB, coded value is 3 1H 34H. 
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Calling Line Indication Presentation (CLIP) Indication 

See internal call CLIP indication clause 8.x.x. The terminal identity number can be used in 
«CALLING-PARTY-NUMBER» information element. 
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